System and method for providing certificate validation and other services

ABSTRACT

A system and method for facilitating electronic commerce by securely providing certificate-related and other services including certificate validation and warranty is disclosed. In a preferred embodiment, these services are provided within the context of a four-corner trust model. The four-corner model comprises a buyer, or subscribing customer, and a seller, or relying customer, who engage in an on-line transaction. The buyer is a customer of a first financial institution, or issuing participant. The issuing participant operates a certificate authority and issues the buyer a hardware token including a private key and a digital certificate signed by the issuing participant. The seller is a customer of a second financial institution, or relying participant. The relying participant operates a certificate authority and issues the buyer a hardware token including a private key and a digital certificate signed by the relying participant. The system also includes a root certificate authority that operates a certificate authority that issues digital certificates to the issuing and relying participants. At the time of a transaction, the buyer creates a hash of the transaction data, signs the hash, and transmits the transaction data, the signature, and its digital certificate to the seller. The seller may then request system services via a connection with its financial institution, the relying participant. The system services may include a certificate status check service and a warranty service. The certificate status check service allows the relying customer to validate the subscribing customer&#39;s certificate. The warranty service allows the relying customer to receive a collateral-backed warranty that the subscribing customer&#39;s certificate is valid. Each participant and the root entity is provided with a transaction coordinator for combining services and operations into a single transaction having the qualities of atomicity, consistency, isolation, and durability. The transaction coordinator provides a single consistent interface for certificate-status messages and requests, as well as messages and requests relating to other services.

[0001] This application claims priority from U.S. provisional patentapplication serial No. 60/231,319, filed Sep. 8, 2000, entitledTransaction Coordinator Certificate Status Check (CSC) ProtocolDefinition, Transaction Coordinator Messaging Protocol Definition, andTransaction Coordinator Requirements, which is hereby incorporated byreference. This application is also a continuation of U.S. patentapplication Ser. No. 09/657,605, filed Sep. 8, 2000, entitled System andMethod for Providing Certificate Validation and Other Services, whichclaimed priority to U.S. provisional patent application serial No.60/153,726, filed Sep. 13, 1999, entitled Transaction Coordinator forCertificate Status Checking and Other Services; U.S. provisional patentapplication serial No. 60/153,724, filed Sep. 13, 1999, entitledTransaction Coordinator Requirements and High Level Design; and U.S.provisional patent application serial No. 60/153,203, filed Sep. 10,1999, entitled System and Process for Certification in ElectronicCommerce, all of which are hereby incorporated by reference.

FIELD OF THE INVENTION

[0002] This invention relates generally to the field of facilitatingelectronic commerce by providing services via a public keyinfrastructure.

BACKGROUND OF THE INVENTION

[0003] The world of electronic commerce has created new challenges toestablishing relationships between contracting parties. One of thosechallenges springs from the fact that the parties to the transactioncannot see or hear each other, and cannot otherwise easily confirm eachother's identity and authority to act.

[0004] One remedy for this problem is to provide each contracting partywith a private key for signing transmitted messages. The signing partymakes available an associated public key that decrypts messages signedwith the party's private key, and thus enables a receiving party toconfirm the identity of the sender.

[0005] But the sender's public key may not be known a priori to therecipient. In that event, the sender may transmit with its signedmessage a digital certificate issued by a certificate authority. Thecertificate is itself a signed electronic document (signed with theprivate key of the certificate authority) certifying that a particularpublic key is the public key of the sender.

[0006] In some cases, the recipient may be unfamiliar with the publickey of the certificate authority or may not know whether the certificateis still valid. In that event, the recipient may wish to check theauthenticity and validity of the certificate with an entity that ittrusts. One known protocol for checking certificate status is theon-line certificate status protocol (OCSP).

SUMMARY OF THE INVENTION

[0007] A system and method are disclosed for facilitating electroniccommerce by securely providing certificate-related and other servicesincluding certificate validation and warranty. In a preferredembodiment, these services are provided within the context of afour-corner trust model. The four-corner model comprises a buyer,referred to as the subscribing customer, and a seller, referred to asthe relying customer, who engage in an on-line transaction. The buyer isa customer of a first financial institution, referred to as an issuingparticipant. The issuing participant acts as a certificate authority forthe buyer and issues the buyer a hardware token including a private keyand a digital certificate signed by the issuing participant. The selleris a customer of a second financial institution, referred to as therelying participant. The relying participant acts as a certificateauthority for the seller and issues the buyer a hardware token includinga private key and a digital certificate signed by the relyingparticipant. The system also includes a root certificate authority thatissues digital certificates to the issuing and relying participants.

[0008] At the time of a transaction, the buyer creates a hash of thetransaction data, signs the hash, and transmits the transaction data,the signature, and its digital certificate to the seller. The seller maythen request system services via a connection with its financialinstitution, the relying participant.

[0009] In a preferred embodiment, these system services may include acertificate status check service and a warranty service. The certificatestatus check service allows the relying customer to validate thesubscribing customer's certificate. The warranty service allows therelying customer to receive a collateral-backed warranty that thesubscribing customer's certificate is valid. Detailed message flows forproviding these services are provided in the detailed description.

[0010] In a preferred embodiment, each participant and the root entityis provided with a transaction coordinator for combining services andoperations into a single transaction having the qualities of atomicity,consistency, isolation, and durability. The transaction coordinatorprovides a single consistent interface for certificate-status messagesand requests, as well as messages and requests relating to otherservices. As a result, the present invention provides the necessaryflexibility to permit centralized and consistent capture oftransactional information relating to a plurality of offered servicesfor audit and non-repudiation purposes. In addition, the presentinvention facilitates the integration of additional services andprovision of those services to customers.

[0011] The disclosed transaction coordinator provides a single interfaceto facilitate electronic communications amongst banks or other financialinstitutions or between banks or other financial institutions and theircustomers. The transaction coordinator also provides a single entrypoint for customers to obtain certificate-check services and providesthe flexibility to add new business application services, such aswarranty service, payment guarantee service, or certified mail service,while still providing a single entry point for these additionalservices. It is preferably designed to be easily extended to supportadditional services as they are created.

[0012] The disclosed transaction coordinator provides parsing, flowcontrol, and error handling for the present messaging infrastructure andacts as a message switch to route message components to an appropriatesystem service (e.g., to an OCSP responder, warranty engine, etc.). Inaddition, it collates responses from these services into a consolidatedresponse and dispatches the responses to requesting clients.

[0013] The disclosed transaction coordinator also records billing datafor the certificate check service or other services in a centralizedgeneral fashion. Because all of the banks and other financialinstitutions have their own requirements for billing, the billing datacan be extracted and modified to an individual financial institution'sneeds by writing simple extraction functions.

[0014] The disclosed transaction coordinator also allows banks or otherfinancial institutions to cross-charge each other for different types oftransactions as needed. Further, the disclosed transaction coordinatorallows for the integration of commercial off-the-shelf softwareapplications and provides a single electronic signing service toelectronically sign and verify documents.

[0015] In addition, the disclosed transaction coordinator isolates allcore services, thereby promoting reuse of components and simplifying themaintenance and enhancements of these services. The disclosedtransaction coordinator does not require changing the on-linecertification check functionality that would render it non-standard andmight result in vendor locking and implementation delays.

BRIEF DESCRIPTION OF THE DRAWINGS

[0016] These and other objects, features, and advantages of the presentinvention will be better understood when taken in conjunction with thefollowing detailed description and accompanying drawings in which:

[0017]FIG. 1 is a block diagram of a preferred embodiment of thefour-corner model employed by the present system;

[0018]FIG. 2 is a block diagram depicting components preferably providedat entities in the four-corner model;

[0019]FIG. 3 is a block diagram of a preferred embodiment of atransaction coordinator;

[0020]FIG. 4 is a composite block/flow diagram that demonstrates certainaspects of transaction coordinator operation in a preferred embodiment;

[0021]FIG. 5 is a composite block/flow diagram depicting preferredoperation of the signing component of a transaction coordinator;

[0022]FIG. 6 is a composite block/flow diagram demonstrating a preferredembodiment of the steps performed by a transaction coordinator inperforming a certificate status check;

[0023]FIG. 7 is a composite block/flow diagram illustrating a preferredembodiment of the transaction flow for validating a certificate;

[0024]FIG. 8 is a composite block/flow diagram illustrating thetransaction flow for one preferred embodiment of a warranty service;

[0025]FIG. 9 is a composite block/flow diagram of a preferred embodimentof server-side authentication;

[0026]FIG. 10 is a composite block/flow diagram of a preferredembodiment of client-side authentication;

[0027]FIG. 11 is a composite block/flow diagram illustrating a preferredmessage authentication process;

[0028]FIG. 12 is a composite block/flow diagram of a preferredembodiment of the security-relevant flows associated with components ofa transaction coordinator;

[0029]FIG. 13 is a composite block/flow diagram that depicts the(estimated) sizes of messages that are passed between system entities ina preferred embodiment;

[0030]FIG. 14 is a composite block/flow diagram that depicts thetransaction flows for an OCSP-proxy centric embodiment of the presentsystem.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0031] The present disclosure relates to a system that allows financialinstitutions to securely perform electronic certificate status checksand other services for their customers. In a preferred embodiment, thedisclosed system employs a four-corner trust model to provide theseservices. A preferred embodiment of the four-corner model employed bythe present system is shown in FIG. 1.

[0032] As shown in FIG. 1, the four-corner model comprises a firstinstitution 102 and a second institution 104. First institution 102 isreferred to as the “issuing participant” because it is a participant inthe present system and issues smart cards to its customers, as describedbelow. Second institution 104 is referred to as the “relyingparticipant” because it is a participant in the present system and itscustomers rely on representations made by issuing participant 102 andissuing participant 102's customers, as described below. Participants102, 104 are typically banks or other financial institutions.

[0033] Also shown in FIG. 1 are a first customer 106, and a secondcustomer 108. First customer 106 and second customer 108 are preferablycustomers of issuing participant 102 and relying participant 104,respectively. First customer 106 is referred to as the “subscribingcustomer” because it subscribes to services provided by issuingparticipant 102. Second customer 108 is referred to as the “relyingcustomer” because it relies on representations made by both issuingparticipant 102 and subscribing customer 106.

[0034] Also shown in FIG. 1 is a root entity 110. Root entity 110 istypically an organization that establishes and enforces a common set ofoperating rules for facilitating electronic commerce and electroniccommunications. Root entity 110 may be owned jointly by a plurality ofbanks and/or other financial institutions that have agreed to adhere tothese operating rules. One exemplary embodiment of such a root entity isdescribed in copending application Ser. No. 09/502,450, filed Feb. 11,2000, entitled System and Method for Certification-Related and OtherServices, which is hereby incorporated by reference.

[0035]FIG. 2 is a block diagram depicting components preferably providedat entities in the four-corner model. As shown in FIG. 2, participants102, 104 and root entity 110 are each provided with a transactioncoordinator 202 that serves as a gateway for transmitting and receivingall inter-entity messages related to services provided by the presentsystem. As described in more detail below, transaction coordinators 202provide a single interface to issuing participant 102's and relyingparticipant 104's on-line services, and implement safeguards necessaryto ensure secure electronic communications between transactioncoordinators 202 and other entities in the four-corner model. Onepreferred embodiment of a transaction coordinator 202 is described belowin connection with FIGS. 3-6.

[0036] Participants 102, 104 and root entity 110 are each furtherpreferably provided with an OCSP responder 204 and hardware securitymodule (HSM) 206. Exemplary requirements for an OCSP responder 204 aredescribed below. HSM 206 is adapted to sign messages and verifysignatures on messages, as described below, in connection with FIG. 6.

[0037] In addition, each participant 102, 104 and root entity 110 isfurther preferably provided with a billing data database 208 (connectedto a bank billing application 210 in the case of participants 102, 104),a raw transaction log, 212, a customer data database 214, a risk manager216 (connected to customer data database 214), and a second hardwaresecurity module 218, each of which is connected to transactioncoordinator 202.

[0038] As further shown in FIG. 2, relying customer 108 is preferablyprovided with a Web server 220 that is adapted to receive and transmitinformation via the Internet. Relying customer 108 is further preferablyprovided with a bank interface 222 for communicating with relyingparticipant 104, as described in more detail below. One preferredembodiment of bank interface 222 (as well as additional componentspreferably provided at the relying customer) is described in copendingU.S. patent application Ser. No. 09/657,604, filed Sep. 8, 2000,entitled System and Method for Facilitating Access By Sellers toCertificate-Related and Other Services, which is hereby incorporated byreference. Relying customer 108 is preferably further provided with ahardware security module 230 for signing and verifying system messages.

[0039] As further shown in FIG. 2, subscribing customer 106 ispreferably provided with a Web browser 224 for browsing the Internet anda smart card 226 (and associated reader) for signing digital messages,as described below.

[0040] In a preferred embodiment, each system entity is provided withtwo digital certificates (and corresponding private keys) to facilitateauthentication: An identity certificate (also referred to, in somecases, as a warranty certificate) and a utility certificate. Inaddition, in a preferred embodiment, each transaction coordinator 202 ispreferably provided with its own identity certificate and utilitycertificate and associated private keys.

[0041] The identity private key is used to produce digital signaturesthat are required by root entity 110 as evidence of an entity'scontractual commitment to the contents of an electronic transaction. Acertificate chain is needed to support operations using this key. Thestatus of the identity certificate may be obtained by authorizedentities, as described below.

[0042] The utility private key is used to produce digital signaturesthat allow additional transactional security. Typically, utilitycertificates are used to support secure socket layer sessions, to signS/MIME messages, and for other utility applications. A certificate chainis also needed to support operations using the utility key. The statusof the utility certificate, however, may not be available to arequestor. Throughout this document, the term “certificate” refers to anidentity certificate unless otherwise stated.

[0043] In a preferred embodiment, subscribing customer 106's digitalcertificates and associated private keys are provided to it by issuingparticipant 102. Issuing participant 102 preferably issues smart cardsor other suitable instruments to subscribing customer 106 that includeat least the private key associated with the subscribing customer'sidentity certificate. If desired, the smart card may also include thesubscribing customer's identity certificate. Preferred specificationsfor the smart card, its manufacture, and contents are described in U.S.provisional patent application serial No. 60/224,994, filed Aug. 14,2000, entitled Signing Interface Requirements, Smart Card ComplianceRequirements, Warranty Service Functional Requirements, and AdditionalDisclosure, which is hereby incorporated by reference.

[0044]FIG. 3 is a block diagram of a preferred embodiment of atransaction coordinator 202. As shown in FIG. 3, transaction coordinator202 preferably comprises an interface 302 comprising two components: aTC request manager 304 and a transport services component 306. Interface302 passes communications to and from a plurality of service modules 308and core components 310. Service modules 308 preferably include acertificate status check module 312, warranty service module 314, apayment guarantee module 316, and may comprise other service modules 318for providing additional services. Core components 310 preferablyinclude a logging component 320, a billing component 322, and a signingcomponent 324.

[0045] Transport services component 306 provides a single entry pointinto the transaction coordinator and acts as an isolation layer betweena requestor and the transaction coordinator's service modules and corecomponents. Request manager 304 receives service requests from transportservices component 306 and forwards them to appropriate service modulesand/or core components, as described in more detail below.

[0046] The function of certificate status check service 312 is tovalidate the certificates of entities within system 200 of FIG. 2. Thefunction of warranty service 314 is to guarantee the identity of anentity that signs an electronic communication relating to a particularbusiness transaction. In a preferred embodiment, the participantproviding the warranty, typically issuing participant 102, acceptsfinancial responsibility for some or all of the transaction amount if itis later discovered that subscribing customer 106 did not execute adigital signature created with the subscribing customer's private key.

[0047] The function of payment guarantee service 316 is to furtherdecrease the risk associated with a transaction by providing relyingcustomer 108 with immediate confirmation of subscribing customer 106'sability to fulfill a financial obligation. In addition, issuingparticipant 102 may issue a payment guarantee for some or all of thetransaction amount if for some reason subscribing customer 106 fails topay relying customer 108. Payment services may also be established asdescribed in copending U.S. patent application Serial No. 09/657,622,filed Sep. 8, 2000, entitled System and Method for Providing PaymentServices in Electronic Commerce, which is hereby incorporated byreference.

[0048] The function of certified mail service 318 is to support off-linetransactions. Off-line transactions occur when the receiving entity,instead of servicing the request immediately, puts the request in aprocessing queue. Typically, an acknowledgment of receipt is sent to therequestor. This scenario may preferably be implemented when thetransaction volumes are so large that it is not feasible to provideon-line responses to every request. Certified mail service 318 maypreferably be used to satisfy requests between relying customer 108 andrelying participant 104, relying participant 104 and issuing participant102, and any request made to root entity 110.

[0049] The function of logging component 320 is to log all servicerequests and OCSP responses in a raw transaction log 58 (see FIG. 5) fornon-repudiation and security auditing purposes.

[0050] The function of billing component 322 is to create and store atransaction billing history for messages (responses and requests)received by transaction coordinator 202. Preferred operation of thesemodules and components is further described below.

[0051]FIG. 4 is a composite block/flow diagram that demonstrates certainaspects of transaction coordinator operation in a preferred embodiment.As shown in FIG. 4, in step 4002, transport services component 306 oftransaction coordinator 202 receives a service request from anothersystem entity and sends the service request to request manager 304. Instep 4004, request manager 304 checks to see if the service requestformat is valid. If the service request format is valid, request manager304 requests information on the requestor, the billing data, and theservice request type by calling a message validation module 404. Messagevalidation module 404 calls a parser component 406 to extract therelevant information from the raw service request.

[0052] In step 4006, request manager 304 calls an authentication module408 to authenticate the requestor. Authentication module 408 isdescribed in more detail below.

[0053] In step 4008, authentication module 408 authenticates therequestor by calling signing component 324 of transaction coordinator202 which, in turn, calls hardware security module 218. A preferredstructure and operation for signing component 324 is described in moredetail below.

[0054] In step 4010, authentication module 408 calls certificate statuscheck component 414 that in turn calls an OCSP responder 204 to performa certificate status check on the requestor. A preferred structure andoperation for certificate status check component 414 is described inmore detail below.

[0055] In step 4012, authentication module 408 calls a customerauthorization check module 418 to verify that the requestor isauthorized to place the service request. A preferred structure andoperation for customer authorization check module 418 is described inmore detail below.

[0056] In step 4014, request manager 304 calls logging component 320 tolog the raw service request for non-repudiation purposes. In a preferredembodiment, messages stored in the raw transaction log are stored ineither ASN.1 or XML format.

[0057] In step 4016, request manager 304 forwards any billing datanecessary to appropriately bill for services provided to billingcomponent 322 to for logging in the billing log.

[0058] In step 4018, request manager 304 forwards the service request toa service request router 426. In step 4020, service request router 426calls an appropriate service module 308 to fulfill the request.

[0059] In step 4022, a service response is received by service requestrouter 426 from the service module that was called in step 4020. Servicerequest router 426 forwards the service response back to request manager304 which, in turn, sends the service response to transport servicescomponents 306. Transport services component 306 forwards the serviceresponse to the entity that made the service request.

[0060]FIG. 5 is a composite block/flow diagram depicting preferredoperation of signing component 324. Signing component 324 preferablyprovides a single interface to different signing devices, such as smartcards and hardware security modules, and uses cryptographic processingto verify signatures.

[0061] Turning to FIG. 5, when a request is received by signingcomponent 324 in step 5002, signing component 324 determines whether itis a request for signature or for verification. If the request is forverification, signing component 324 sends the request to a hardwaresecurity module 218 for verification (step 5004). In step 5008, hardwaresecurity module 218 responds to this request with a signatureverification response to signing component 60.

[0062] If the request is to sign a document, signing component 324 sendsthe request (which should include the document to be signed) to hardwaresecurity module 218 for signature (step 5006). In step 5010, hardwaresecurity module 218 responds to this request by signing the document andreturns the signed document to signing component 324. Finally, in step5012, signing component 324 returns the signature-verification responseor signed document to the component that made the request.

[0063]FIG. 6 is a composite block/flow diagram demonstrating a preferredembodiment of the steps performed by a transaction coordinator 202 inperforming a certificate status check. In step 6002, certificate checkservice module 312 receives an unparsed certificate status check requestfrom service router 426 and forwards it to a parser component 406 thatextracts the relevant customer information (comprising the certificateto be checked) from the request. In step 6004, certificate check servicemodule 312 obtains any additional service-specific fulfillmentinformation from a customer database 606.

[0064] In step 6006, if the certificate to be checked belongs to acustomer of the participant whose transaction coordinator 202 receivedthe request, certificate check service module 312 hands the request offto a local-customer handler 602. Otherwise, certificate check servicemodule 312 hands the request off to a non-local-customer handler 610.

[0065] In those cases where local-customer handler 602 handles therequest, the system proceeds to step 6008, where local customer handler602 sends a certificate check request to a certificate status checkcomponent 312. Certificate status check component 312 then obtains acertificate status for the certificate to be checked from its associatedOCSP responder 204 (i.e., the OCSP responder 204 belonging to the sametransaction coordinator 202 as certificate status check component 312).Flow in these cases then continues with step 6032 below.

[0066] In contrast, in those cases where the certificate to be checkeddoes not belong to a customer of the participant who received therequest, then, in step 6010, non-local-customer handler 610 looks up theIP address of the issuing participant that issued the certificate thatis the subject of the request in a static DNS table 604. Transactioncoordinator 202 _(RP) is preferably adapted to use the AIA extension ina certificate to identify the location of issuing participant 102. Instep 6012, non-local-customer handler 610 forwards the subjectcertificate to an OCSP request formulation module 608. In step 6014,OCSP request formulation module 608 formulates an OCSP request for thecertificate and sends the request to signing component 324 forsignature. In step 6016, signing component 324 returns the signedrequest.

[0067] In step 6018, OCSP request formulation module 608 sends thesigned request to the issuing participant 102 that issued the subjectcertificate. In step 6020, that issuing participant 102 returns an OCSPresponse to the request to OCSP request formulation module 608.

[0068] In step 6022, OCSP request formulation module 608 forwards theresponse to non-local-customer handler 610. In step 6024,non-local-customer handler 610 logs the raw response data to rawtransaction log 212 for non-repudiation purposes.

[0069] In step 6026, non-local-customer handler 610 sends the rawresponse data to parser component 406 to extract the certificates ofissuing participant 102 and its transaction coordinator 202 _(IP) fromthe response.

[0070] In step 6028, non-local-customer handler 610 validates theissuing participant's transaction coordinator certificate by repeatingsteps 6012-6024 but transmitting the OCSP request created in step 6014to root entity 110 rather than issuing participant 102.

[0071] Similarly, in step 6030, non-local-customer handler 610 validatesthe issuing participant's certificate by repeating steps 6012-6024 buttransmitting the OCSP request created in step 6014 to root entity 110rather than issuing participant 102.

[0072] In step 6032, the certification check response data received bynon-local-customer handler 610 or generated by local-customer handler602 is sent to signing component 324 which signs the response. In step6034, the signed response is sent back to certificate check servicemodule 312 which, in turn, transmits the response to service requestrouter 426.

[0073]FIG. 7 is a composite block/flow diagram illustrating a preferredembodiment of transaction flow within system 200 for validating acertificate. As shown in FIG. 7, in step 7002, subscribing customer 106creates a hash of data representing a transaction between subscribingcustomer 106 and relying customer 108 and sends the hash to smart card226 for signature. In step 7004, smart card 226 signs the data andreturns the signed data along with the certificate of subscribingcustomer 106 and issuing participant 102.

[0074] In step 7006, subscribing customer 106 sends the signed data andthe two certificates to relying customer 108. In step 7008, relyingcustomer 108 verifies the signature on the data sent by subscribingcustomer 106. This verification preferably includes checking thevalidity period of the received certificates. Alternatively,verification may be provided as a service to relying customer 108 byrelying participant 104. Relying customer 108 then creates an OSCPrequest containing the subscribing customer's and issuing participant'scertificates and transmits the request to hardware security module 230for signature. In step 7010, hardware security module 230 returns thesigned request.

[0075] In step 7012, relying customer 108 transmits the signed OCSPrequest to relying participant 104, along with its own certificate. Instep 7014, transaction coordinator 202 _(RP) of relying participant 104receives the signed OCSP request and checks customer database 214 _(RP)to make sure that the request was signed by an existing relying customerbefore processing the request. In a preferred embodiment, a relyingparticipant 104 does not process requests received from a customer of adifferent participant. In step 7016, transaction coordinator 202 _(RP)stores the raw transaction data (i.e., the unparsed request, signature,and accompanying relying customer certificate) in raw transaction log212 _(RP). In step 7018, any billing data necessary to appropriatelybill for services provided is stored in billing log 208 _(RP).Alternatively, billing data may be extracted from the raw-transactionlog by an off-line process to increase system performance.

[0076] In step 7020, transaction coordinator 202 _(RP) verifies therelying customer's signature on the service request using the relyingcustomer's certificate, the relying participant's certificate, and theroot public key. The relying participant's certificate and the rootpublic key may preferably be stored in hardware security module 218_(RP).

[0077] In step 7022, transaction coordinator 202 _(RP) generates an OCSPrequest containing the relying customer's certificate, signs it, andsends it to its OSCP responder 204. Alternatively, if the transactioncoordinator and OCSP responder are co-located, a signature on therequest may not be necessary. In step 7024, OCSP responder 204 verifiesthe signature of the request, checks its local repository to determinethe validity of its relying customer's certificate, and sends a responseback concerning that certificate's status to transaction coordinator 202_(RP).

[0078] It should be noted that, as part of system operation, relyingcustomers 108 will often need to validate the certificate of asubscribing customer 106 that is a customer of a participant other thanrelying participant 104. Because, in that case, relying participant 104is not the issuing participant that issued the certificate to bevalidated, it does not have first hand knowledge of that certificate'sstatus.

[0079] In a preferred embodiment, the present system addresses thisproblem by having each participant that receives an OCSP request for acertificate issued by another participant, forward the request to theissuing participant for that certificate. In particular in step 7026,relying participant 104 determines the subscribing customer's issuingparticipant. If the subscribing customer is a customer of a differentparticipant, relying participant 104 generates a signed validationrequest for the subscribing customer's certificate and sends it to theidentified issuing participant 102 along with its own certificate.Alternatively, rather than sign the validation request, the relyingparticipant may instead provide client-side authentication to issuingparticipant 102 as, for example, in the OCSP-proxy centric modeldescribed below.

[0080] If the subscribing customer and the relying customer are bothcustomers of the same participant, validation of the subscribingcustomer's certificate is handled by local-handler module 602, asdescribed above.

[0081] In step 7028, issuing participant 102 checks its customerdatabase 214 _(IP) to make sure that the request was signed by an entityauthorized to make the request. In step 7030, issuing participant 102stores the received raw transaction (i.e., the unparsed request,signature, and accompanying certificate) in its raw transaction log 212_(IP). In step 7032, issuing participant 102 stores relevant billingdata for the request in its billing log 208. Alternatively, billing datamay be extracted from the raw-transaction log by an off-line process toincrease system performance.

[0082] In step 7034, issuing participant 102 verifies transactioncoordinator 202 _(RP)'s signature on the request using the relyingparticipant's transaction coordinator certificate (sent with therequest) and the root public key (which may be stored in hardwaresecurity module 218 _(IP)). In step 7036, the issuing participant'stransaction coordinator 202 _(IP) generates a signed OCSP request forthe relying participant's transaction coordinator certificate and sendsthe request to root entity 110.

[0083] In step 7038, transaction coordinator 202 _(R) of root entity 110receives the request and stores the raw request in its raw transactionlog 212 _(R). In step 7040, transaction coordinator 202 _(R) storesbilling data for the request in billing data log 208 _(R). In step 7042,transaction coordinator 202 _(R) verifies the signature on the requestand then sends the request to OCSP responder 204 _(R). In step 7044,OCSP responder 204 _(R) checks its local repository to determine thestatus of the subject certificate and sends a response back concerningits status to transaction coordinator 202 _(R). In step 7046,transaction coordinator 202 _(R) sends a signed response to transactioncoordinator 202 _(IP) indicating the status of the relying participant'stransaction coordinator certificate.

[0084] In step 7048, transaction coordinator 202 _(IP) of issuingparticipant 102 stores the OCSP response from root entity 110 in rawtransaction log 212 _(IP) for non-repudiation purposes. In step 7050,transaction coordinator 202 _(IP) generates an OCSP request for thesubscribing customer's certificate, signs it, and sends it to its ownlocal OCSP responder 204 _(IP) along with its own certificate.Alternatively, if transaction coordinator 202 _(IP) and OCSP responder204 _(IP) are co-located, a signature on the request may not benecessary. Also, if the two are co-located, the transaction coordinatormay simply act as a pass through, as opposed to re-signing requests andresponses.

[0085] In step 7052, OCSP responder 204 _(IP) verifies the signature onthe request, generates a response, signs it, and returns the signedresponse to transaction coordinator 202 _(IP). In step 7054, transactioncoordinator 202 _(IP) verifies the OCSP responder's signature, resignsthe response, and returns it to transaction coordinator 202 _(RP) alongwith its own certificate.

[0086] In step 7056, transaction coordinator 202 _(RP) of relyingparticipant 104 stores the raw response data received from issuingparticipant 102 in raw transaction log 212 _(RP) for non-repudiationpurposes. In step 7058, transaction coordinator 202 _(RP) verifies thesignature of transaction coordinator 202 _(IP) on the response using theissuing participant's transaction coordinator certificate (sent with therequest) and the root public key (which may be stored in hardwaresecurity module 218 _(RP)). In step 7060, transaction coordinator 202_(RP) generates a signed OCSP request for the issuing participant'stransaction coordinator certificate and sends it to root entity 110.

[0087] In step 7062, transaction coordinator 202 _(R) of root entity 110stores the raw request data in raw transaction log 212 _(R). In step7064, transaction coordinator 202 _(R) stores relevant billing data inbilling log 208 _(R). In step 7066, transaction coordinator 202 _(R)verifies the signature on the request and sends the request to OCSPresponder 204 _(R). In step 7068, OCSP responder 204 _(R) checks itslocal repository to determine the status of the issuing participant'stransaction coordinator certificate and sends a response back concerningits status to transaction coordinator 202 _(R). In step 7070,transaction coordinator 202 _(R) sends a signed response concerning thestatus of the subject certificate to transaction coordinator 202 _(RP).

[0088] In step 7072, transaction coordinator 202 _(RP) of relyingparticipant 104 stores the response in raw transaction log 212 _(RP) fornon-repudiation purposes. At this point, processing of the subscribingcustomer's certificate is complete.

[0089] In step 7074, transaction coordinator 202 _(RP) now processes thesecond half of the request: the issuing participant's certificate, bygenerating a signed OCSP request for the issuing participant'scertificate and sending it to root entity 110.

[0090] In step 7076, transaction coordinator 202 _(R) of root entity 110stores the raw request data in raw transaction log 212. In step 7078,transaction coordinator 202 _(R) stores relevant billing data in billinglog 208.

[0091] In step 7080, transaction coordinator 202 _(R) verifies thesignature on the request and sends the request to OCSP responder 204_(R). In step 7082, OCSP responder 204 _(R) checks its local repositoryto determine the status of the subject certificate and sends a responseback to transaction coordinator 202 _(R). In step 7084, transactioncoordinator 202 _(R) sends a signed response to transaction coordinator202 _(RP).

[0092] In step 7086, transaction coordinator 202 _(RP) of relyingparticipant 104 stores the response from root entity 110 in rawtransaction log 212 _(RP) for non-repudiation purposes. In step 7088,transaction coordinator 202 _(RP) creates an OCSP response from theresponses received from transaction coordinator 202 _(IP) of issuingparticipant 102 and its local cache, signs it, and sends it to relyingcustomer 108 along with its own certificate.

[0093] In step 7090, relying customer 108 verifies the response usingthe root's public key certificate stored in hardware security module230. In step 7092, relying customer 108 sends a request to transactioncoordinator 202 _(RP) for the relying participant's transactioncoordinator certificate in order to determine if that certificate hasbeen revoked. In step 7094, transaction coordinator 202 _(RP) verifiesthe signature on the request and sends a request to local OCSP responder204 _(RP) to ensure that the relying customer's transaction coordinatorcertificate has not been revoked. In step 7096, local OCSP responder 204_(RP) responds to this request from transaction coordinator 202 _(RP).

[0094] In step 7098, transaction coordinator 202 _(RP) sends an OCSPrequest for the relying participant's transaction coordinatorcertificate to transaction coordinator 202 _(R) of root entity 110. Instep 7100, transaction coordinator 202 _(R) verifies the signature onthe request and checks with local OCSP responder 204 _(R) to determinethe status of the relying participant's transaction coordinatorcertificate. In step 7102, transaction coordinator 202 _(R) forwards theresponse received from local OCSP responder 204 _(R) to transactioncoordinator 202 _(RP).

[0095] In step 7104, transaction coordinator 202 _(RP) forwards theresponse received from root entity 110 to relying customer 108. In step7106, relying customer 108 provides acknowledgment to subscribingcustomer 106.

[0096] In connection with steps 7092-7104 above, it should be notedthat, as part of system operation, relying customers 108 will typicallyneed to obtain the status of relying participant 104's transactioncoordinator certificate. Within the four-corner model, the transactioncoordinator and OCSP responder certificates of issuing participant 102and relying participant 104 are signed by root entity 110. While rootentity 110 operates an OCSP responder, this service is accessible onlyto participants. Consequently, relying customer 108 cannot requestvalidation of its relying participant's certificates directly from rootentity 110.

[0097] In a preferred embodiment, the present system addresses thisproblem by having each participant 102, 104 operate a root responderproxy. This proxy accepts requests from customers on behalf of the root,typically through a different uniform resource locator, forwards therequest to the root over an authenticated secure sockets layer channel,and returns the response (still signed by the root) to the requestingparty.

[0098] The four-corner model described above may also be used to providea warranty service that warranties the identity of a particular entity(e.g., the subscribing customer) that signed a transaction. Oneembodiment for providing such a warranty service is described below.Additional embodiments for providing warranty services are described inU.S. provisional patent application serial No. 60/224,994, filed Aug.14, 2000, entitled Signing Interface Requirements, Smart Card ComplianceRequirements, Warranty Service Functional Requirements, and AdditionalDisclosure, which is hereby incorporated by reference.

[0099]FIG. 8 is a diagram of the transaction flow for one preferredembodiment of a warranty service. As shown in FIG. 8, in step 8002,subscribing customer 106 creates a hash of date representing atransaction between subscribing customer 106 and relying customer 108and sends the hash to smart card 226 for signature. In step 8004, smartcard 226 signs the data and returns the signature along with thesubscribing customer's certificate and the issuing participant'scertificate. Optionally, this message may also include card andsignature security data (CSSD) to inject additional security such asprotection against duplicate messages.

[0100] In step 8006, subscribing customer 106 sends the signed data, thesignature, the subscribing customer's certificate, and the issuingparticipant's certificate (and optionally the CSSD) to relying customer108. In step 8008, relying customer 108 verifies the signature on thedata sent by subscribing customer 106. Alternatively, verification maybe provided as a service to relying customer 108 by relying participant104. Relying customer 108 then creates a warranty request and transmitsthe request to hardware security module 230 for signature. In step 8010,hardware security module 230 returns the signed request along with acopy of the relying customer's certificate.

[0101] In step 8012, relying customer 108 sends the signed warrantyrequest and relying customer certificate to relying participant 104.

[0102] In step 8014, transaction coordinator 202 _(RP) of relyingparticipant 104 checks customer database 214 _(RP) to make sure that therequest was signed by an existing customer before processing therequest. In step 8016, transaction coordinator 202 _(RP) stores the rawtransaction data relating to the transaction (i.e., the “unparsed”request, signature, and accompanying certificate) in raw transaction log212 _(RP). In step 8018, transaction coordinator 202 _(RP) storesrelevant billing data in billing log 208 _(RP). Alternatively, billingdata may be extracted from the raw transaction log by an off-lineprocess to increase system performance.

[0103] In step 8020, transaction coordinator 202 _(RP) verifies therelying customer's signature on the request using the relying customer'scertificate (sent with the request), the relying participant'scertificate, and the root public key (both of which may be stored inhardware security module 218 _(RP)). Transaction coordinator 202 _(RP)then generates an OCSP request containing the relying customer'scertificate, signs it, and sends it to its local OCSP responder 204_(RP). Alternatively, if the transaction coordinator and OCSP responderare co-located, a signature on the request may not be necessary.

[0104] In step 8022, OCSP responder 204 _(RP) verifies the signature onthe request, check its local repository for the status of the relyingcustomer's certificate, and sends a response concerning that status backto transaction coordinator 202 _(RP).

[0105] In step 8024, transaction coordinator 202 _(RP) calls a riskmanager 216 _(RP) to determine if relying customer 108 is financiallyauthorized to make the warranty request. If it is, then, in step 8026,transaction coordinator 202 _(RP) determines the participant responsiblefor responding to warranty requests concerning subscribing customer 106(i.e., the participant of which subscribing customer 106 is a customer).In the present example, this entity is issuing participant 102.Transaction coordinator 202 _(RP) then creates a warranty request forsubscribing customer 106, signs it, and sends it to issuing participant102 along with its own certificate. It should be noted that if therelying customer and subscribing customer are both customers of the sameparticipant, the warranty request may instead be processed locally bythe participant.

[0106] In step 8028, transaction coordinator 202 _(IP) checks customerdatabase 214 _(IP) to make sure that the request was signed by an entityauthorized to make the request. In step 8030, transaction coordinator202 _(IP) stores the raw transaction data (i.e., the “unparsed” request,signature, and accompanying certificate) in raw transaction log 212_(IP). In step 8032, transaction coordinator 202 _(IP) stores relevantbilling data for the request in the billing log 208 _(IP).Alternatively, billing data may be extracted from the raw transactionlog by an off-line process to increase system efficiency. In step 8034,transaction coordinator 202 _(IP) verifies transaction coordinator 202_(RP)'s signature on the request using transaction coordinator 202_(RP)'s certificate (sent with the request), and the root public key(which may be stored in hardware security module 218 _(IP)). Transactioncoordinator 202 _(IP) then generates a signed OCSP request for therelying participant's transaction coordinator certificate and sends itto root entity 110.

[0107] In step 8036, transaction coordinator 202 _(R) of root entity 110stores the raw request in raw transaction log 212 _(R). In step 8038,transaction coordinator 202 _(R) stores relevant billing data for therequest in billing data log 208 _(R). In step 8040, transactioncoordinator 202 _(R) verifies the signature on the request and thensends the request to OCSP responder 204 _(R). OCSP responder 204 _(R)checks its local repository to determine the status of relyingparticipant's transaction coordinator certificate and sends a responseconcerning that status back to transaction coordinator 202 _(R).Transaction coordinator 202 _(R) then sends a signed response back totransaction coordinator 202 _(IP).

[0108] In step 8042, transaction coordinator 202 _(IP) of issuingparticipant 102 stores the raw response in raw transaction log 212 _(IP)for non-repudiation purposes. In step 8044, transaction coordinator 202_(IP) then generates an OCSP request from the request it receivedcontaining the subscribing customer's certificate, signs it, and sendsit to its local OCSP responder 204 _(IP) along with its own certificate.Alternatively, if the transaction coordinator and OCSP responder areco-located, as signature on the request may not be necessary. Also, ifthe two are co-located, the transaction coordinator may simply act as apass through as opposed to re-signing requests or responses.

[0109] In step 8046, OCSP responder 204 _(IP) verifies the signature onthe request, generates a response, signs it, and returns the signedresponse to transaction coordinator 202 _(IP). In step 8048, transactioncoordinator 202 _(IP) calls risk manager 216 _(IP) to determine whetheror not to issue a warranty for subscribing customer 106. In step 8050,risk manager 216 _(IP) returns a signed message to transactioncoordinator 202 _(IP) indicating whether a warranty should be issued. Instep 8052, transaction coordinator 202 _(IP) stores the signed responsein raw transaction log 212 _(IP).

[0110] In step 8054, transaction coordinator 202 _(IP) sends a signedrequest to transaction coordinator 202 _(R) of root entity 110 todetermine if issuing participant 102 has enough collateral to issue thewarranty. In step 8056, transaction coordinator 202 _(R) interacts withrisk manager 216 _(R) to determine if issuing participant 102 isadequately collateralized and, if so, decreases issuing participant102's collateral level by an amount appropriate for the warranty beingissued and returns a response to issuing participant 102.

[0111] In step 8058, transaction coordinator 202 _(IP) verifiestransaction coordinator 202 _(R)'S signature, creates a warrantyresponse, and returns it to transaction coordinator 202 _(RP) along withits certificate.

[0112] In step 8060, transaction coordinator 202 _(RP) of relyingparticipant 104 stores the raw response in raw transaction log 212 _(RP)for non-repudiation purposes. In step 862, transaction coordinator 202_(RP) verifies transaction coordinator 202 _(IP)'s signature on theresponse using transaction coordinator 202 _(IP)'s certificate (sentwith the response), and the root public key (which may be stored inhardware security module 218 _(RP)). Transaction coordinator 202 _(RP)then creates a signed OCSP request for the issuing participant'stransaction coordinator certificate and sends it to root entity 110.

[0113] In step 8064, transaction coordinator 202 _(R) of root entity 110stores the raw request in raw transaction log 212 _(R). In step 8066,transaction coordinator 202 _(R) stores relevant billing data in billinglog 208 _(R). In step 8068, transaction coordinator 202 _(R) verifiesthe signature on the request. Transaction coordinator 202 _(R) thensends the request to its OCSP responder 204 _(R). OCSP responder 204_(R) checks its local repository to determine the status of the subjectcertificate and sends a response back to transaction coordinator 202_(R). Transaction coordinator 202 _(R) then sends a signed response totransaction coordinator 202 _(RP).

[0114] In step 8070, transaction coordinator 202 _(RP) of relyingparticipant 104 stores the raw response data in raw transaction log 212_(RP) for non-repudiation purposes. In step 8072, transactioncoordinator 202 _(RP) checks with transaction coordinator 202 _(R) ofroot entity 110 to ensure that the issuing participant has sufficientcollateral to issue the warranty.

[0115] In step 8074, transaction coordinator 202 _(R) stores the rawrequest in raw transaction log 212 _(R). In step 8076, transactioncoordinator 202 _(R) stores relevant billing data in billing log 208_(R). In step 8078, transaction coordinator 202 _(R) sends a yes or noresponse to transaction coordinator 202 _(RP) of relying participant 104concerning whether issuing participant 102 has sufficient collateral toissue the warranty.

[0116] In step 8080, transaction coordinator 202 _(RP) stores the rawresponse data in raw transaction log 212 _(RP) for non-repudiationpurposes. In step 8082, transaction coordinator 202 _(RP) creates awarranty response from the responses received from transactioncoordinator 202 _(IP), signs it, and sends it to relying customer 108along with transaction coordinator 202 _(RP)'s certificate.

[0117] In step 8084, relying customer 108 verifies the response usingthe root public key stored in hardware security module 230. In step8086, relying customer 108 sends a request to transaction coordinator202 _(RP) for transaction coordinator 202 _(RP)'s certificate to see ifit has been revoked.

[0118] In step 8088, transaction coordinator 202 _(RP) verifies thesignature on the request and sends a request to its local OCSP responder204 _(RP) to ensure that relying customer 108's transaction coordinatorcertificate has not been revoked. In step 8090, local OCSP responder 204_(RP) sends a response to this request to transaction coordinator 202_(RP). In step 8092, transaction coordinator 202 _(RP) sends an OCSPrequest for its certificate to transaction coordinator 202 _(R).

[0119] In step 8094, transaction coordinator 202 _(R) verifies thesignature on the request and checks with its local OCSP responder 204_(R) to determine the status of transaction coordinator 202 _(RP)'scertificate. Transaction coordinator 202 _(R) then forwards the responsereceived from local OCSP responder 204 _(R) to transaction coordinator202 _(RP).

[0120] In step 8096, transaction coordinator 202 _(RP) forwards theresponse received from transaction coordinator 202 _(R) to relyingcustomer 108. In step 8098, relying customer 108 sends an acknowledgmentto subscribing customer 106.

[0121] In a preferred embodiment, each transaction coordinator 202provides atomicity, consistency, isolation, and durability totransactions coordinated by the transaction coordinator. Atomicity meansthat all actions required to complete a transaction succeed or all fail;the transaction is an indivisible unit of work. Consistency means thatafter a transaction is executed, the system is left in a correct, stablestate, or returns to the state preceding initiation of the transaction.Isolation means that each transaction is unaffected by othertransactions that may execute concurrently. Durability means that theeffects of each transaction are permanent after the transaction iscommitted. The combination of atomicity, consistency, isolation, anddurability are sometimes referred to as ACID properties.

[0122] Transaction coordinators 202 preferably provide ACID propertiesin a distributed computing environment by incorporating a transactionprocessing monitor or component transaction monitor. Suitabletransaction processing monitors may include BEA TUXEDO from BEA Systems,Inc., MSMQ from Microsoft, Top End from NCR Corporation, and Encina fromIBM Transarc. Suitable component transaction monitors may include OrbixOTM from Iona Technologies Inc. and BEA WebLogic from BEA Systems, Inc.

[0123] Any combination of steps to be coordinated by a transactioncoordinator may be combined to form a transaction having the ACIDproperties. Preferably, one or more pre-defined transactions areprovided for each of the process flows depicted in FIGS. 5-7. Thus, forexample, the steps occurring between the request and response depictedin FIG. 5 may be combined to form a transaction having ACID properties.

[0124] In a preferred embodiment, transaction coordinator componentsinteract with the transaction processing monitor via a transactionprocessing library. To facilitate a flexible architecture whereby theimplemented transaction processing monitor may be replaced with analternate transaction processing monitor, libraries may be written toaccess transaction-processing-monitor functionality regardless of theparticular brand of transaction processing monitor used.

[0125] Each of the above-listed transaction processing monitors hascertain features that relate to its suitability for incorporation in atransaction coordinator of the present system. For example, TUXEDOtransaction process monitors are designed to provide: (1) ahigh-performance message-passing engine (2) distributed transactionmanagement, allowing clients and servers to participate in a distributedtransaction and to manage two-phase commit processes transparently toapplications (3) an application to transaction manager interfaceallowing developers to write BEA TUXEDO applications regardless of thehardware hosting program (4) dynamic workload balancing thatautomatically generates and manages parallel copies of applications andensures that they are evenly utilized (5) transaction queuing thatallows distributed applications to work together in an asynchronous,connectionless fashion and that prioritizes queues based on messagecontext, content, and time of day (6) data dependent routing thatenables transactions to be processed where the data can be mostefficiently utilized (7) automatic recovery from application failures,transaction failures, network failures, and node failures in which theserver manager restarts the failed process and recovers the failedprogram by rolling back the transaction that was in progress.

[0126] MSMQ transaction processing monitors from Microsoft are designedto provide: (1) full COM component support (2) access from a range ofprogramming languages (e.g. Visual C++, Visual J++) (3) five APIs (open,close, receive, send, and locate) providing advanced message queuingbenefits (4) sliding-window protocols, recoverable storage, dynamicrouting to deliver messages, and on-time, in-order message delivery (5)the ability to be included within transactions that contain otheractivities, such as database updates (6) the ability to commit or abortoperations with other resources to preserve data integrity duringtransactions (7) built-in message encryption, integrity, and signaturesupport and (8) administrators the ability to specify which MSMQ eventsshould create an audit record in the Windows NT Security Log.

[0127] MSMQ is typically included as a feature of both MS Windows NTServer, Standard Edition 4.0 and MS Windows NT Server, and EnterpriseEdition 4.0. If support for more than twenty-five clients, cost-basedrouting, or the MSMQ Connector is needed, MSMQ is preferably run on NTServer and Enterprise Edition 4.0. It should be noted that although MSMQis a high-performance message-passing engine, it does not have necessaryfeatures of a transaction process monitor, and therefore may not besuitable for use in the present system.

[0128] IBM Encina is available from Transarc on many hardware platformsincluding Sun, IBM, Digital Equipment Corp., Hewlett Packard, andWindows. IBM Encina transaction processing monitors are designed toprovide: (1) interoperability to allow the development of distributedtransaction processing applications that integrate a wide variety ofsystems (2) concurrent use of multiple XA-compliant databases orresource managers, such as Oracle, Ingres, Informix, or Sybase throughan X/Open XA application programming interface and provide mainframeLU6.2 interoperability, including sync-level 0, 1, and 2 services,without requiring additional software on the mainframe (3) performanceand reliability required by transaction processing applications (4) anefficient, fully-distributed two-phase commit mechanism (5) automaticload balancing and replication of application servers to increaseperformance and to eliminate single points of failure (6) inheritedsecurity mechanisms of the underlying DCE thereby allowing both clientsand servers to verify the identities and privileges of participants in atransaction (7) additional security mechanisms, including automatedauthorization checking and facilities to allow the construction of audittrail records (8) enterprise-wide scalability in order to support largenumbers of users and large amounts of data and (9) a centralizedadministration facility to permit effective management.

[0129] Top End transaction processing monitors are designed to provide:(1) robust middleware (2) distributed transaction management (3)client/server interaction (4) reliable file transfer (5) dynamicworkload balancing (6) recoverable transaction queuing (7) applicationparallelization (8) two-phase commit processing (9) automatic recovery(10) message-sensitive routing (11) multiple database support (MicrosoftSQL Server, Oracle, and Sybase) and (12) Internet applicationscalability and availability.

[0130] In a preferred embodiment, each transaction coordinator in thepresent system is adapted to provide a plurality of security servicesincluding: authentication, authorization, session security, messagesecurity, non-repudiation, and auditing.

[0131] In a preferred embodiment, the transaction coordinator uses PKIXauthentication based on a PKI defined by root entity 110. Otherauthentication mechanisms for services outside the present system may besupported as determined by the entity operating the transactioncoordinator.

[0132] In a preferred embodiment, authentication is provided through theuse of digital signatures. Authentication may take place at the sessionlevel, the message level, or both.

[0133] In a preferred embodiment, the secure socket layer protocolprovides session level authentication. The secure sockets layer protocolconsists of two phases: server-side authentication and optionalclient-side authentication. A given transaction coordinator 202 acts asa server when it receives requests from a customer or anothertransaction coordinator and as a client when it transmits a request toanother transaction coordinator.

[0134]FIG. 9 depicts server-side authentication. A server 90 receives arequest from a client 95 (step 9002), and sends its utility certificateto the client (step 9004). In step 9006, client 95 generates a publickey, encrypts it with the server's public key and sends it to server 90(step 9006). In step 9008, server 90 uses its private key to recover thepublic key sent by client 95, and authenticates itself to client 95 byreturning a message authenticated with the public key received from theclient. Subsequent data is encrypted and authenticated with keys derivedfrom the client-generated public key.

[0135] Secure socket layer server-side authentication allows client 95to know with whom it is communicating. Server-side authentication ispreferably required for all sessions over which network transactionstake place. In order to authenticate server 90, client 95 must possessthe public key certificate of the root certificate authority in server90's utility certificate chain.

[0136]FIG. 10 depicts optional client-side authentication. In step10002, server 90 sends a challenge to client 95. Client 95 authenticatesitself to server 90 by signing the challenge with its private key andreturning the signed challenge, with its public key certificate, to theserver (step 10004).

[0137] Secure socket layer client-side authentication ensures thatclient 95 possesses a valid utility certificate and the accompanyingprivate key. As noted, in a preferred embodiment, secure socket layerclient-side authentication is optional but is employed if relying andissuing participants 104 and 102 do not require digitally signedrequests from clients 95. Transaction coordinators 202 _(IP), 202 _(RP),and 202 _(R) must possess the public key certificate of the rootcertificate authority in the client's utility certificate chain in orderto determine that client 95 holds a valid root certificate.

[0138] In a preferred embodiment, at the session level, issuingparticipant 102 and relying participant 104 authenticate themselves totheir customer clients. Issuing participant 102 and relying participant104 may also require customer clients to authenticate themselves totransaction coordinators 202 _(IP), 202 _(RP), and 202 _(R) at the timea session is established. Thus, if client 95 is not an authorizedcustomer of the participant with which it is communicating, thetransaction coordinator for that participant may terminate the sessionbefore processing a message. Participants may also require customerclient-side authentication at the session level in lieu of requiringmessage level authentication.

[0139] As noted, authentication between transaction coordinators 202_(IP), 202 _(RP), and 202 _(R) may occur either at the session level orat the message level, or both. In contrast, relying customers arepreferably required to provide authentication at the message level bydigitally signing all requests sent to transaction coordinator 202_(RP). However, as previously mentioned, a participant may also requirerelying customers to provide client-side authentication at the sessionlevel.

[0140]FIG. 11 is a composite block/flow diagram illustrating a preferredmessage authentication process. As will be described, this processoperates to authenticate messages (responses or requests) sent totransaction coordinators 202 by applying a digital signature to datacontained in the message.

[0141] In step 1102, an authentication module 408 calls hardwaresecurity module 218 to verify the signature on a received message usingthe sender's public key certificate typically sent with the message. Instep 1104, authentication module 408 calls hardware security module 206to check that the sender possesses a valid root warranty certificate byvalidating the sender's certificate chain, beginning with the root'scertificate in the sender's chain. Portions of the sender's chain, suchas the sender's public key certificate, are sent with the message. Otherportions of the chain may be previously stored in HSM 206 and/orcustomer database 214, such as the root's certificate.

[0142] In step 1106, authentication module 408 calls a time source 11 toobtain the current time and verify that none of the certificatescomprising the sender's chain have expired. All participants and rootentity 110 are preferably provided with synchronized time sources.

[0143] In step 1108, authentication module 408 calls OCSP responder 204to check that the certificates in the signer's chain, other than thosestored in hardware security module 218, have not been revoked.

[0144] Message authentication provides a stronger level ofauthentication than session authentication. Session authentication usesutility keys. In general, OCSP checks are not performed on utility keys,therefore neither a client nor a server will learn during theauthentication process if an SSL certificate has been revoked. Inaddition, utility keys are stored unprotected so that anyone inpossession of the token on which the key is stored can masquerade as theauthorized user. Warranty keys, on the other hand, which are used toprovide message authentication, are protected so that merely possessingthe token is not sufficient to gain access to the key and masquerade asthe authorized user.

[0145] In a preferred embodiment, customer authorization check module418 (see FIG. 5) checks to make sure the requestor of a service isauthorized to receive that service. For purposes of determiningauthorization, the requestor's identity may be determined from sessionlevel authentication or message level authentication. Preferably,customer authorization check module 418 performs an authorization checkby extracting the user's authenticated identity or distinguished namefrom its presented utility or warranty certificate, and comparing thisagainst a list of authorized users in customer database 214. In apreferred embodiment, the customer authorization check may be based on apart of the distinguished name, such as any user with a distinguishedname subordinate to the financial institution's certificate authority'sdistinguished name, or it can be based on the entire distinguished name,such that only specific users are authorized.

[0146] Customer authorization check module 418 may perform authorizationchecks at multiple levels. For example, it may have the capability toallow or deny services at the user level, or to allow or deny servicesbased on finer criteria, such as the amount of collateral a user has.

[0147] In a preferred embodiment, transaction coordinators 202 providesession security using a secure socket layer (SSL). SSL typicallyprovide three levels of session security: confidentiality, dataintegrity, and session authentication. Preferably, all communications toand from transaction coordinators 202 are encrypted using SSL.

[0148] Message security in the present system is preferably providedthrough the use of digital signatures. Digital signatures provide twolevels of message security: authentication and data integrity. Digitalsignatures typically provide authentication through the use of protectedprivate keys, which are used for signing messages.

[0149] As noted above, digital signatures preferably provide dataintegrity through the use of a hash or message digest that is generatedduring the signature process. Message digests provide a “fingerprint” ofthe data such that if any bit of the signed data is modified, adifferent “fingerprint” will result and the recipient of the data willnot be able to verify the signature.

[0150] In a preferred embodiment, confidentiality is provided at thesession level for all root communications. The transaction coordinatorpreferably complies with confidentiality rules specified by root entity110.

[0151] In a preferred embodiment, each transaction coordinator 202records all data needed to ensure non-repudiation of a performed servicein logs and ensures the integrity of those logs. For example, relyingparticipant 104 preferably provides such non-repudiation for allservices it performs for relying customer 108. Thus, for each serviceperformed, transaction coordinator 202 _(RP) not only provides aresponse to relying customer 108 but also retains all data necessary toensure that none of the parties involved in performing the service canrepudiate having provided the service.

[0152] In a preferred embodiment, digitally signed messages provide thebasis for this non-repudiation. As noted, for example, in the context ofthe validation service described above, transaction coordinators 202maintain a log of all received messages for non-repudiation purposes.Preferably, transaction coordinators 202 log messages exactly asreceived and do not parse, modify, or store messages in any format otherthan the format in which they were received. Modification of receivedmessages renders the message's digital signature unverifiable and thusmakes the message unsuitable for non-repudiation purposes.

[0153] In a preferred embodiment, each received message is time stampedas part of the non-repudiation service. Responses are associated withauthorization checks performed at a certain point in time. Preferably,the time of the authorization check is a signed attribute in theresponse and is captured in raw transaction log 212.

[0154] In a preferred embodiment, transaction coordinator 202 also logsinformation for auditing purposes. Security audit logs may be used todetect potential attacks against the system, such as a suspicious numberof requests from non-customers or a suspicious number of invalidsignatures. Security audit logs may also assist when a key compromiseoccurs because a key may be compromised before it is reported and itsassociated certificate is revoked. The security audit logs maypreferably be used to determine if transactions occurred using acompromised key.

[0155] An audit trail is maintained for purposes of dispute resolution,non-repudiation, and billings. In a preferred embodiment, a transactioncoordinator logs every message that it sends or receives and logs theentire message. Messages may be logged in “raw” format. Alternatively,the transaction coordinator may break the message into its constituentparts and store it in a schema such that the entire message can bereconstructed in a manner that preserves the signature. In a preferredembodiment, logs are of such a nature that log entries cannot befalsified (added/deleted/altered) without being detected. In addition,if a transaction coordinator logs a message in raw format, it preferablyincludes the capability to convert the raw data into a format readableby a COTS solution. This may be a loosely coupled utility or a part ofthe transaction coordinator functionality that runs as a separate andperhaps lower priority I background process. It may also run on anentirely separate system. The logs may contain other data related to thetransport and the session. As an example this may include,sender/recipient IP address, the URL of the post, SMTP header etc.

[0156] Transport services component 306 (shown in FIG. 3) preferablycomprises a secure communications component that establishes a securesocket layer session between transaction coordinator 202 and the entitywith which it is communicating. In a preferred embodiment, the securecommunication component performs session authentication, as describedabove. Thus, when transaction coordinator 202 acts as a server 90, thesecure communications component provides server-side sessionauthentication and may request client-side session authentication. Incontrast, when transaction coordinator 202 acts as a client 95, thesecure communications component is responsible for authenticating server90.

[0157] As a client, transaction coordinator 202 is also preferablyresponsible for establishing session security by generating a sessionkey and sending the key, which is encrypted with the server's publickey, to the transaction coordinator server with which it wants tocommunicate. Subsequent communications between the two parties areencrypted with that session key.

[0158]FIG. 12 is a composite block/flow diagram that depicts a preferredembodiment of the security-relevant flows associated with components oftransaction coordinators 202. As shown in FIG. 12, in step 1202, arequest is received by transport services component 306. In step 1204,transport services component 306 delivers the request to request manager304. Preferably, request manager 304 ensures that all security-relatedfunctions are performed on incoming messages before the messages areprocessed.

[0159] In step 1206, request manager calls logging component 320 to logthe raw request data. Logging component 320 gathers the data required tosupport non-repudiation and auditing. As noted above, all requests andresponses are preferably logged as received.

[0160] In step 1208, request manager 304 determines if a signature onthe request is required. In step 1210, if request manager 304 determinesthat the request does not need to be signed, request manager 304 callscustomer authorization check module 54 with the client's utilitycertificate.

[0161] In step 1212, if request manager 304 determines that a signatureis required, request manager 304 calls customer authentication module408. In step 1214, customer authentication module 408 verifies thesignature on the request and validates the certificate chain by callingsigning component 324.

[0162] Preferably, signing component 324 provides message security andsupports the session and message authentication services. Signingcomponent 324 interfaces with hardware security module 218, whichperforms all cryptographic functions. Root 110 preferably specifies thedigital signature method that will be used to sign all transactions.Signing component 324 preferably interfaces with hardware securitymodule 218 to perform all cryptographic functions involved in thesignature verification process.

[0163] In step 1216, customer authentication module 408 checks thestatus of the customer's warranty certificate by sending a request toOCSP responder 204 via certificate status check component 414, asdescribed above.

[0164] In step 1218, customer authentication module 110 calls customerauthorization check module 418 with the customer's warranty certificate.In step 1220, customer authorization check module 418 checks customerdatabase 214 to make sure the request came from a customer authorized toobtain the requested service. In step 1222, a response regardingauthorization is returned to request manager 304 and processing ofsystem provided services continues as described above.

[0165] Preferred security requirements for network communicationsbetween transaction coordinators and the following entities: customers,OCSP responders, and other transaction coordinators will now bedescribed. These preferred requirements are described in the context ofan example in which relying customer 108 submits a request to relyingparticipant 104.

[0166] When transaction coordinator 202 _(RP) of relying participant 104receives a request from a relying customer 108, transaction coordinator202 _(RP) authenticates the request. Signatures are typically requiredon all messages sent to transaction coordinator 202 _(RP) by relyingcustomer 108. In addition, transaction coordinator 202 _(RP) may requirerelying customer 108 to provide secure socket layer client-side sessionauthentication.

[0167] Preferably, transaction coordinator 202 _(RP) providesauthentication of all messages it sends to relying customer 108. Inaddition, transaction coordinator 202 _(RP) provides secure socket layerserver-side session authentication when any session is established withrelying customer 108.

[0168] In a preferred embodiment, transaction coordinator 202 _(RP)performs authorization checks to determine if relying customer 108 is anexisting customer of relying participant 104. Transaction coordinator202 _(RP) may also perform authorization checks to determine if relyingcustomer 108 is authorized to receive the type or level of service beingrequested. Preferably, relying customer 108 has an entry in customerdatabase 214 _(RP) that lists the services to which it is entitled.Preferably, relying customer 108 is identified by a distinguished nameas it exists in its warranty certificate and may also be identified byits distinguished name as it exists in its utility certificate if securesocket layer client-side session authentication is employed. This aspectof the transaction coordinator may be integrated with COTS accesscontrol/authorization packages.

[0169] In a preferred embodiment, transmissions between relying customer108 and transaction coordinator 202 _(RP) are encrypted in accordancewith specifications specified by root entity 100 and server-sideauthentication is required.

[0170] Typically, messages exchanged between relying customer 108 andtransaction coordinator 202 _(RP) are digitally signed. Preferably,transaction coordinator 202 _(RP) verifies all signed messages received,validates the certificate chain, and ensures that the certificateswithin the chain have not been revoked. In addition, transactioncoordinator 202 _(RP) signs all messages it sends to relying customer108.

[0171] In a preferred embodiment, transaction coordinator 202 _(RP)provides a non-repudiation service for relying customer 108. Transactioncoordinator 202 _(RP) typically logs all responses relating to requestsfor service received from any root component. This includes othercomponents of transaction coordinator 202 _(RP) as well as components ofother participants and root 110. Preferably, relying participant 104logs all requests for services from relying customer 108 and allacknowledgments received from relying customer 108 indicating thereceipt of a response in order to protect itself from repudiation claimsfrom its customers.

[0172] In a preferred embodiment, transaction coordinator 202 _(RP) logsall requests for services from relying customer 108 for auditingpurposes. Accordingly, a system administrator can detect potentialattacks against the system and determine if requests for services werereceived after a key compromise occurred. Auditing of requests may alsobe used to support any billing disputes that may arise.

[0173] In a preferred embodiment, transaction coordinators 202 _(IP),202 _(RP), and 202 _(R) communicate respectively with OCSP responders204 _(IP), 204 _(RP), and 204 _(R) only, i.e., OCSP responders that arewithin their financial institution. To request a response from an OCSPresponder 204 at another financial institution, communications mustpreferably go through the other financial institution's transactioncoordinator 202.

[0174] Preferably, OCSP responders 204 _(IP), 204 _(RP), and 204 _(R)know the identity of the entity from which they are receiving a requestand transaction coordinators 202 _(IP), 202 _(RP), and 202 _(R) know theidentity of the entity from which they are receiving an OCSP response.Preferably, co-located transaction coordinators 202 _(IP), 202 _(RP),and 202 _(R) and OCSP responders 204 _(IP), 204 _(RP), and 204 _(R) knowthat they are receiving messages from a local process without anyexplicit authentication. In this case, neither secure socket layerauthentication nor signed requests are required. However, OCSPresponders 204 _(IP), 204 _(RP), and 204 _(R) may typically sign allresponses and transaction coordinators 202 _(IP), 202 _(RP), and 202_(R) may typically accept signed responses in accordance with theInternet PKI OCSP specification.

[0175] If transaction coordinators 202 _(IP), 202 _(RP), and 202 _(R)and OCSP responders 204 _(IP), 204 _(RP), and 204 _(R) are notco-located and cannot ascertain unambiguously with whom they arecommunicating, authentication between the components is preferablyrequired. Authentication of requests may be either at the session levelor the message level. Authentication of responses is preferably at themessage level and may be at the session level, as well.

[0176] It should be recognized that transaction coordinators 202 _(IP),202 _(RP), and 202 _(R) do not typically perform authorization checks onOCSP responders 204 _(IP), 204 _(RP), and 204 _(R) since OCSP responders204 _(IP), 204 _(RP), and 204 _(R) do not typically request servicesfrom transaction coordinators 202 _(IP), 202 _(RP), and 202 _(R).

[0177] Because OCSP responders 204 are preferably co-located with theirrespective transaction coordinators 202, transmission securitymechanisms do not typically have to be provided for communicationsbetween them. Because the two components are contained within a physicalenvironment that is completely under the control of one financialinstitution, protection can preferably be provided through policy asopposed to implementation of security mechanisms.

[0178] However, if these components are not co-located, thetransmissions are preferably protected against network attacks thatcould compromise the confidentiality or the integrity of thetransmissions. Preferably, SSL is used to provide this protection.

[0179] In a preferred embodiment, each OCSP responder 204 is co-locatedwith its respective transaction coordinator 202 and transactioncoordinator 202 therefore need not sign OCSP requests. However, OCSPresponder 204 may sign responses if required by specifications specifiedby root entity 110.

[0180] In cases where OCSP responses are signed, they are preferablylogged with the signature of the responder intact, in particular whenthe response is directly related to the service being provided. However,if transaction coordinator 202 has requested an OCSP response as part ofan authentication check on a request for service, the OCSP response istypically not logged for non-repudiation purposes. This is because theOCSP check is performed to determine whether or not to process theincoming request, not as part of processing the request itself. Onlyinformation relating to the processing of the request is necessary toretain for non-repudiation purposes. In a preferred embodiment, localOCSP responses are typically only logged when relying participant 104 isalso issuing participant 102 of the certificate in question and the OCSPrequest is part of the process for providing a service, e.g., checkingthe subscribing customer's certificate during a validation request forthat certificate.

[0181] In a preferred embodiment, there are no requirements to log OCSPresponses for security auditing purposes because OCSP responders 204 donot request services of transaction coordinators 202. In addition, thereare no requirements to log OCSP requests generated by transactioncoordinators 202 for security auditing purposes because transactioncoordinator 202 cannot audit itself.

[0182] Preferably, transaction coordinators authenticate all requestsfrom other transaction coordinators. This is typically accomplishedeither by secure socket layer client-side authentication or by afinancial institution configuring its transaction coordinator to requiresignatures on all requests from other transaction coordinators.

[0183] In a preferred embodiment, a first transaction coordinator thatreceives a request from a second transaction coordinator performs anauthorization check to determine if the requesting transactioncoordinator is authorized to make the request. This authorization checkis facilitated by providing all authorized transaction coordinators 202_(IP), 202 _(RP), and 202 _(R) with an entry in the customer database ofthe transaction coordinator from which they desire to obtain service. Iftransaction coordinator 202 from whom services are being requestedrequires a signature, the requestor may preferably be identified by itsdistinguished name as it exists in its warranty certificate. If not,identification from its utility certificate should preferably bepermitted only if secure socket layer client-side authentication isrequired.

[0184] Preferably, transmissions between relying customer 108 andtransaction coordinator 202 _(RP) are encrypted and server-side sessionauthentication is required.

[0185] A participant may require that all requests sent to itstransaction coordinator from other transaction coordinators be signed.In lieu of this, a participant may require secure socket layerclient-side session authentication. Preferably, transaction coordinators202 _(IP), 202 _(RP), and 202 _(R) sign all responses being sent toother transaction coordinators.

[0186] Preferably, transaction coordinators 202 _(IP), 202 _(RP), and202 _(R) provide a non-repudiation service. To this end, transactioncoordinators 202 _(IP), 202 _(RP), and 202 _(R) log all responsesrelating to a request for service received from other transactioncoordinators.

[0187] Preferably, all requests for services received by transactioncoordinators 202 _(IP), 202 _(RP), and 202 _(R) will be logged forauditing purposes. This enables a system administrator to detectpotential attacks against the system and also enables the systemadministrator to determine if requests for services were received aftera key compromise occurred. Auditing of requests may also be used tosupport any billing disputes that may arise.

[0188] Preferred architectural components of a transaction coordinatorare now discussed in greater detail.

[0189] Components of a transaction coordinator are preferablyimplemented as customized software code although other software productsmay be used as described herein. In addition to this code, a participantmay write and implement its own additional service modules. Thus,participants may implement their own business specific rules for thecertificate status check service described above and other services thatmay be offered via the four-corner model.

[0190] In a preferred embodiment, a customer software development kit isused as a tool-set to facilitate the interface between transactioncoordinator 202 and customers or other transaction coordinators. Thesoftware development kit is preferably integrated with transportservices component 306. The software development kit is preferablyadapted to intercept all hyper-text transfer protocol requests destinedfor an application's original web server at a web site maintained byrelying customer 108. The software development kit preferably determineswhether the message needs to be signed based on a defined set of rules.The customer software development kit also authenticates signatures andpublic key certificates with the help of hardware security module 230. Apreferred embodiment of one such SDK is described in copending U.S.patent application Ser. No. 09/657,604, filed Sep. 8, 2000, entitledSystem and Method for Facilitating Access By Sellers toCertificate-Related and Other Services, which is hereby incorporated byreference.

[0191] Depending upon the breadth of the features provided by thesoftware development kit, its usage may preferably be expanded to otherareas of transaction coordinator operation. Certain modifications andadditional functionality are typically required in order for thesoftware development kit to be used within the transaction coordinator.

[0192] A Microsoft™ SQL server may preferably be used as the databasefor storing billing data. Preferably, transaction coordinator 202 isadapted to interact with the server via a database library.Alternatively, interaction with the server may be done using JAVA™Database Connectivity if the transaction coordinator development is donein JAVA™. In addition, database libraries may be written for otherservers thereby permitting the replacement of a Microsoft SQL server byanother database without impacting transaction coordinator 202.

[0193] Preferably, Microsoft's MS SQL Server provides the followingfeatures and functionality: (1) Online Analytical Processing (OLAP)Services to efficiently analyze complex information essential toreporting, data analysis, decision support, and data modeling (2)on-disk storage architecture (3) a Multiphase Query Optimizer (4) autostatistics to enable the query optimizer to use the latest informationand to increase query efficiency (5) active backup to provide highperformance online backup with minimal impact on operational systems (6)merge replication to allow users to work independently, then combinetheir work later (7) built-in priority-based conflict resolution toresolve merge conflicts (8) ability to publish data on the Web (9) adata transformation service to simplify the process of importing andtransforming data from multiple, heterogeneous sources (10) ability tocheck physical and logical database consistency (11) dynamic row-levellocking (17) a query optimizer that manages statistics gathering andguaranteeing an efficient plan (13) an intra-query parallel execution ofa single query across multiple processors to improve performance; stepsin a single query are executed in parallel thereby delivering an optimumresponse time (14) a redesigned query processor to better support thelarge databases and complex queries found in decision support, datawarehousing, and Online Analytical Processing applications (15) sortspeed (16) multiple triggers per table and direct recursion of triggers(17) dynamic memory to optimize memory allocation and usage and dynamicmemory management (18) parallel backup and the ability to restoreutilities scale at device speeds (19) smart read-ahead logic to improveperformance and to eliminate the need for manual tuning and (20)run-time checks of critical structures.

[0194] Preferably, adequate data is captured and stored to allow theentity that maintains a transaction coordinator to generate billinginvoices on a per transaction basis. To this end, in a preferredembodiment, each and every incoming and outgoing message generated by atransaction coordinator, in its entirety, is stored in successiverecords in a database. Such messages include: all requests received, allrequests made, all responses generated, and all responses received. Thisensures availability of all the necessary data to generate invoices on aper transaction basis.

[0195] Preferably, transaction coordinator 202 records billing data in acentralized general fashion. Participants may obtain records by writingtheir own routines to extract the billing data relevant to theparticipant from the centralized billing data. In addition to providingdata in the database, data may also be provided in EXCEL™ spreadsheets.

[0196] In a preferred embodiment, TymeServe Network Time Server(“TYMSYNC”)™ by Datum Inc. is used as the transaction coordinator's timestamping component. TYMSYNC is a time synchronization package thatacquires time from the Global Positioning System Navstar satelliteconstellation with absolute accuracy to the nearest microsecond relativeto the Universal Time Coordinator as maintained by the United StatesNaval Observatory. This product may be adapted to synchronizeworkstations in TCP/IP (transmission control protocol over internetprotocol) and LAN (local area network) networks. Preferably, time isdistributed within the network using the Network Time Protocol. TYMSYNCmay be configured to continuously synchronize a computer system's clockto the Universal Time Coordinator. The times when requests and responsesare generated and when messages are received and sent are preferablystored for non-repudiation and auditing purposes.

[0197] In a preferred embodiment, all communications with transactioncoordinator 202 are conducted over secure connections. Preferably, thesecure socket layer encryption scheme for synchronous communications isused. Secure socket layers are used in a fashion compatible withcommercial/web server implementations and provide security and privacyover electronic networks such as the Internet. Secure socket layers areapplication independent, thereby allowing protocols to be layeredtransparently on top of them.

[0198] Secure socket layers provide confidentiality, data integrity, andauthentication for all network communications. Secure socket layerstypically ensure confidentiality by encrypting all data being passedbetween the communicating entities. When a secure socket layer-enabledclient 95 and server 90 first communicate, they agree on a protocolversion and select encryption algorithms. Preferably, network endorsedencryption algorithms and key lengths are specified by root entity 110.

[0199] Secure socket layers also typically ensure data integrity throughthe use of encryption. If a message does not decrypt correctly, therecipient can tell that someone has tampered with the message.

[0200] Secure sockets layers also support server and clientauthentication, negotiate encryption keys, and authenticate the serverbefore data is exchanged by the higher-level application. Authenticationis preferably provided through the use of digital signatures and publickey certificates, which are exchanged at the time an electroniccommunication session is first established.

[0201] In a preferred embodiment, each transaction coordinator iscapable of accepting and sending messages over the public Internet usingSMTP to send S/MIME messages and communicating via the HTTP protocolover an SSLv3 connection (HTTPS). In other words, each transactioncoordinator is preferably adapted to support the following two modes ofcommunication:

[0202] HTTP over Secure Sockets Layer (SSLv3) - For synchronouscommunications (i.e. HTTPS). HTTPS is a hypertext transfer protocol thatincorporates secure sockets layer between Web servers and Web browsersin order to transfer Web pages securely. Use of HTTP keep alive isrecommended.

[0203] S/MIME v2 - For asynchronous communication using SMTP.

[0204] In a preferred embodiment, each transaction coordinator acts asan HTTPS server during communications with the relying customer and asan HTTPS client when it makes a request to a transaction coordinator atanother financial institution. In either mode, all SSL communication forcredential status checking may employ only server authentication.

[0205] In a preferred embodiment, each transaction coordinator mayaccept messages delivered via other transport protocols (e.g., IIOP)approved by root entity 110. In addition, participants may implementother transport protocols locally by arrangement. In the absence ofprior agreement, however, only HTTPS support should be assumed.

[0206] In a preferred embodiment, Valicert's™ OCSP responder is used forcertificate status check service 312. However, access to OCSP responder204 may be achieved using libraries. Thus, by writing new libraries, newOCSP responder vendors may be implemented.

[0207] Preferably, OCSP responder 204 determines certificate statuswithout using a certificate revocation list. OCSP responder 204 may movemost of the processing involved to a certificate authority, a componentthat issues, verifies, and revokes certificates, and eliminate the needto download potentially large certificate revocation lists.Alternatively, these functionalities may be divided among differentcomponents which may be provided with separate signing keys. Forexample, the function of issuing certificates may be separated from therevocation function, and components for performing these functions maybe provided with separate signing keys.

[0208] In a preferred embodiment, a hardware security module is used asa signing component. The hardware security module is preferably ahigh-speed device for signing and verifying signatures. The hardwaresecurity module is typically a networked hardware device that providescryptographic services to authenticated entities. A suitable hardwaresecurity module is manufactured by NCipher.

[0209] In a preferred embodiment, transaction coordinator 202 is alwaysavailable to process requests during its normal operating times, whichmay be twenty-four hours a day seven days a week. To make sure thesystem meets availability requirements, a detailed requirement analysisof system-availability should be conducted. Because differentparticipants may have different requirements, many different types offailures may occur. As is known, many different hardware and softwarevendors offer different options for high-availability systems. However,these options may or may not be available for the hardware and softwarethat is chosen by a given financial institution.

[0210] There are a number of known potential hardware failures that mayaffect a transaction coordinator. For example, the power supply to theserver may fail. Preferably, a multiple redundant hot-swap power supplyautomatically swaps to a redundant power supply. If the server fails orcrashes, the transaction coordinator preferably provides for highavailability clustering for automatic fail over. In addition, thetransaction coordinator preferably comprises a self re-start capabilityfor automatically rebooting the server in the event of a networkoperating system (NOS) hang.

[0211] The transaction coordinator also preferably comprises multipleredundant hot-swap disk drives and a disk array controller to handledisk failure or crashes. The transaction coordinator also comprises anetwork interface to provide support for redundant network interfacecards (NICs) in the event of NIC failure. In the event of cooling systemfailure, the transaction coordinator preferably uses redundant hot-swapcooling systems comprising hot swappable redundant fans which areindividually removable. The transaction coordinator also preferablycomprises an Intelligent Platform Management Interface to detecthardware and software failures. The Intelligent Platform ManagementInterface is an open specification which simplifies and standardizescommunications for device management. In the event of memory corruption,the transaction preferably uses self-correcting memory. Theself-correcting memory is preferably a managed error checking andcorrecting system memory and cache memory.

[0212] In the event of application crashes, transaction coordinator 202preferably uses transaction processing monitoring to restart theapplication. The transaction coordinator may also run redundant copiesof an application and the transaction process monitor may transfertransactions to the redundant copies. Certain application availabilityfeatures may require that the application to be coded in a specific waywhich may also help address application crashes.

[0213] In the event of an operating system crash, transactions arepreferably transferred to a standby machine that is supported by thenetwork. Directory services, including middleware like CORBA, may alsobe used to re-direct any new transaction requests to the new machine.

[0214] In addition to the hardware and the software availabilityproducts, a monitoring infrastructure is preferably used to monitor theapplications and the network.

[0215] In a preferred embodiment, a software monitoring tool (such asTrivoli) is used to monitor applications. This tool is preferablyconfigured to page the administrator in the event of applicationfailure. A network monitoring system (such as that made by NetView) mayalso be used to allow administrators to monitor the network.

[0216] Preferably, custom written application daemons are used tosimulate transactions. If these transactions fail, system administratorsmay be informed. Also, database vendor tools may be used for databasemonitoring. Most databases provide database-monitoring tools that detectdeadlocks and other databases problems.

[0217] A distribution approach for the transaction coordinator maypreferably be defined that is a function of what root entity 110 wishesto distribute to participants. Application distribution may typically beperformed via Web-download from root entity 110. The Web-downloadmechanism may provide for selective download, authentication, andtracking.

[0218] In a preferred embodiment, the transaction coordinator may beadapted to support integration with existing operational systems such asCICS, IMS and other legacy systems.

[0219] Participants may choose to use the entire transaction coordinatorarchitecture and functionality described above, or may instead choose touse components of the transaction coordinator and add their ownimplementations to those components. The Web-download approach ispreferably configured to fulfill the varying requirements ofparticipants. The download mechanism preferably provides at least threedownload options: (1) a download transaction coordinator executableoption (2) a source code or binaries of the transaction coordinatoroption and (3) a source code of transaction coordinator classes option.

[0220] The first option preferably accommodates participants that chooseto use the transaction coordinator in its entirety. This option providesoptions for different platforms. The second option preferablyaccommodates participants that choose to plug components of thetransaction coordinator described above into their own implementations.This download mechanism also provides options for different platforms.The third option preferably accommodates financial institutions that optfor heavy-duty development and choose only to use certain pieces ofimplementation of the transaction coordinator described above.

[0221] Preferably, the download mechanism allows financial institutionsto not only download the executable, but also the source code. Becausethe downloaded executable may be used on its own and the source code maybe used to develop other custom applications, root entity 110 preferablyprovides download access only to those institutions that are trustedpartners with root entity 110 and hence are authorized to use thetransaction coordinator. Preferably, this is achieved via anauthentication/authorization process.

[0222] Root entity 110 may preferably track which participants downloadparticular components of the transaction coordinator. This way rootentity 110 may determine the versions of the transaction coordinatorand/or its components that are being used at any given time. Root entity110 may use this information to (1) charge a fee from the financialinstitutions for the downloaded component(s) and to (2) track versionsof the transaction coordinator for maintenance purposes.

[0223] Preferably, the transaction coordinator is adapted to be scalableto accommodate a growing user base without significant performancedegradation. One step in fulfilling the scalability requirements for anapplication is to forecast the potential growth in the user base. Ingeneral, an application with a distributed architecture facilitateshigher scalability by allowing distributed multiple instances of heavilyloaded components to be running at a given time. The transactioncoordinator architecture is preferably a distributed one and, therefore,supports scalability. In addition, the load-capacity of the transactioncoordinator is preferably base-lined on a chosen development machine.This information is used to select appropriate hardware to support theanticipated number of transactions. Preferably, the transactioncoordinator (and OCSP responder) are adapted to reliably handle up to1000 validation transactions per minute.

[0224] As noted above, OCSP checks are typically not performed onutility certificates. If signatures are not required on requests, thereis no mechanism in place to ensure that the secure socket layerclient-side certificates have not been revoked. Preferably, if a securesocket layer certificate has been revoked, financial institutions areinformed out of band (e.g., a broadcast message) and the affected usersare removed from the participant's customer database.

[0225] Each transaction coordinator typically trusts some set ofcertificates that are stored on its hardware security module. No OCSPchecks are performed on these certificates. If a revoked certificateexists on a hardware security module, it will not be detected duringon-line processing. Preferably, financial institutions are notified if acertificate stored on a hardware security module has been revoked sothat they can remove the certificate from the hardware security module.

[0226] Transaction coordinators, when acting as clients, authenticateservers with whom they are communicating. But this check typically onlyguarantees that the server has a certificate that was issued by acertificate authority that the transaction coordinator trusts. There areno checks regarding the identity or status of the server itself. In apreferred embodiment, the transaction coordinator checks servers againsta list of trusted servers and performs OCSP checks of the server'scertificate. However, since there is little to be gained by a serverintercepting requests, the degradation of performance resulting fromthese additional checks is typically not warranted.

[0227] Typically, the transaction coordinator does not have automatedprocesses for detecting potential attacks. Preferably, system andsecurity administrators inspect audit logs periodically in order toidentify such potential attacks.

[0228] Typically, requests that do not pass a secure socket layerclient-side authentication check are not logged. If an attack (e.g., adenial of service attack) occurs at this level, there are no logs toreference.

[0229] In a preferred embodiment, the transaction coordinator isprotected by a firewall. Preferably, the firewall component maintainslogs of incoming requests.

[0230] The transaction coordinator is preferably provided with automatedintrusion detection mechanisms. These processes typically watch incomingtraffic or scan audit logs looking for suspicious activity, and takeappropriate actions if necessary.

[0231] The transaction coordinator preferably maintains logs fornon-repudiation purposes. Often, however, the system will not includefunctions to assist a user in retrieving the data necessary to supportnon-repudiation. The user manually searches through the logs to find allthe supporting data. In other embodiments, automated non-repudiationtools may be used to assist the user in this process.

[0232] In a preferred embodiment, transaction coordinators and OCSPresponders employ normal Internet time out values for certificate statuscheck requests. For other services, the time out value may be set asappropriate for the service. In a preferred embodiment, timeout valuesare configurable in the transaction coordinator.

[0233] The following discussion outlines a possible hardware andsoftware implementation for a transaction coordinator.

[0234] The main server used for the transaction coordinator may be aHewlett Packard Netserver LH4. Preferably, the server has the followingspecifications: 4 P2-450 MHZ processors, 512-768MB RAM, 40-60 GB HD withRaid 5 Array, UPS, and an external DLT 40E DLT 4000 tape drive for tapebackup. Preferably, at least five workstations are used each having thefollowing specifications: P2400 MHz processors, 128 MB RAM, and 6 GB HD.

[0235] The transaction coordinator is preferably platform independent sothat it can be supported on servers based on Microsoft Windows NT4.0/2000, Sun Solaris, and Hewlett Packard HP-UX. Implementation ispreferably done in JAVA however some coding may be done in C/C++ aswell.

[0236] A Windows NT Server w/Service Pack 3 may be used as the operatingsystem. Microsoft Visual SourceSafe 6.0 may be used for source control.Visual Café Professional Edition 3.0 from Symantec (Java Version 1.2)may be used for development. SSL/J SDK from RSA Security Systems may beused for secure socket layer implementation and is also required byXETI's JKIX.

[0237] For signature verification, nCipher's hardware security modulemay be used. For signatures from subscribing customers, Datakey smartcards may be used. Preferably, OCSP responders are provided with atoolkit that provides an interface to cryptographic functions and forASN.1 Communication. In a preferred embodiment, XETI's JKIX may be usedfor this purpose.

[0238] For digital time stamping, Datum's TYMSYNC or other trusted timesource may be used. An MS SQL Server may be used for the databasesdescribed above. Code Warrier from Metro Works may be used for thedevelopment of portable C/C++ development. CodeIntegrity may be used toperform code integrity checks to verify code portability.

[0239] Typically, the size of the data that is passed between differententities is instrumental in the performance of a public keyinfrastructure system. Messages submitted between entities are thereforepreferably analyzed to estimate the size of the data that istransmitted. The analysis may be done on the basis of the certificatefields defined in RFC2459 along with specific root extensions.

[0240] The exact data lengths of the certificate fields, which have afixed length, are preferably taken into account during the estimation.However, there are many fields for which the length varies. For thesefields, a liberal estimate on the size is preferably made (i.e., largerrather than smaller). Also, estimates of overall message size preferablyinclude the sizes for all extensions, i.e., if a message allows fivedifferent extensions, the size is preferably calculated on an assumptionthat all five extensions are being sent with the request.

[0241]FIG. 13 depicts the different message (estimated) sizes passedbetween system entities in a preferred embodiment. As shown in FIG. 13,the total estimated message size of messages passed from subscribingcustomer 106 to relying customer 108 is 2610 bytes. The messagetypically comprises two certificates, each 1146 bytes, the issuingparticipant's certificate signed by root entity 110, 128 bytes, theissuing participant's signature, 128 bytes, and an HTTP header, 62bytes.

[0242] The total estimated message size of messages passed from relyingcustomer 108 to relying participant 104 is 2022 bytes. The messagetypically comprises two requests, one concerning the subscribingcustomer's certificate and one concerning the issuing participant'scertificate, each 55 bytes, a message extension, 210 bytes, a versionnumber, 4 bytes, the relying participant's name, 132 bytes, the relyingparticipant's signature, 128 bytes, the relying customer's certificate,1146 bytes, and an HTTP header, 62 bytes.

[0243] The total estimated message size of messages passed from relyingparticipant 104 to issuing participant 102 is 1601 bytes. The messagetypically comprises a request concerning the subscribing customer'scertificate or the issuing participant's certificate, 55 bytes, amessage extension, 210 bytes, the root entity's signature on the relyingparticipant's transaction coordinator certificate, 128 bytes, therelying participant's transaction coordinator certificate, 1146 bytes,and an HTTP header, 62 bytes.

[0244] The total estimated message size of messages passed from issuingparticipant 102 to relying participant 104 is 2086 bytes. The messagetypically comprises a response concerning either the subscribingcustomer's certificate or the issuing participant's certificate, 456bytes, a message extension, 294 bytes, the issuing participant'scertificate, 1146 bytes, the root entity's signature, 128 bytes, and anHTTP header, 62 bytes.

[0245] The total estimated message size of messages passed from relyingparticipant 104 to relying customer 108 is 2213 bytes. The messagetypically comprises a response concerning the subscribing customer'scertificate or the issuing participant's certificate, 55 bytes, amessage extension, 210 bytes, the response from the relyingparticipant's transaction coordinator, 127 bytes, the relyingparticipant's transaction coordinator certificate, 1146 bytes, the rootentity's signature on the relying participant transaction coordinator'scertificate, 128 bytes, and an HTTP header 62 bytes.

[0246] The detail on message size estimation of different fields isdepicted in the table below. Typically, the size of message being passedbetween the entities is between 2K and 3K. Once the transaction volumehas been projected, this information is preferably used to estimate thenetwork load. Certificate Size - No Extensions or Root Specificinstructions Size (in Certificate { Bytes) Size Calculation CommentTbsCertificate { Version Integer 4 Serial Number 4 Integer signature {Algorithm Object Identifier 11 Parameters Defined by 32 Signaturealgorithm parameters are usually NULL but since Algorithm parameters areallowed, 32 bytes have been assigned for it } issuer Name 132 This is ahigher estimate -- approximated for 4 names. Name is defined as sequenceof Relative Distinguished Name validity { notBefore { utcTime UTCTime 32generalTime GeneralizedTime 32 } notAfter { utcTime UTCTime 32generalTime GeneralizedTime 32 } } subject Name 132 This is a higherestimate - approximated for 4 names. Name is defined sequence ofRelative Distinguished Names subjectPublicKeyInfo { algorithm {Algorithm Object Identifier 11 Parameters Defined by 32 Signaturealgorithm parameters are usually NULL but since parameters are allowed,32 bytes have been assigned for it } subjectPublicKey BIT STRING 128 }issuerUniqueID BIT STRING 132 This is higher estimate. Usually if Issueris defined, issuerUniqueID should not be used subjectUniqueID BIT STRING132 This is higher estimate. Usually if Subject is defined, subjectUniqueID should not be used extensions { extnID Object Identifier 0Certificate is being estimated without any extensions. extnID would take11 bytes. critical BOOLEAN 0 BOOLEAN would take 4 bytes extnValue OCTETSTRING 0 Will depend upon the extension } } signatureAlgorithm {algorithm Object Identifier 11 parameters Defined by 32 Algorithm }Signature Value BIT STRING 128 This may vary from signer to signer Whensigned by root, the sire will be 256 when signed by the root } Total 985

[0247] Certificate Extension - with Root Instructions and ExtensionsSize (in Certificate Extensions/root entry Specific Instructions Bytes)Size Calculation Comments Must not contain Issuer Unique ID −132 Mustnot contain Subject Unique ID −132 Contain a Subject DN 0 Alreadypresent in certificate Extension subjectAltNames is supported as e-mail47 Consists of a number of GeneralNames - root entity will support onlyrfc822 - email address - estimated at 32 bytes + 11 bytes for extnID and4 bytes for critical flag Extension KeyUsage should appear in allCertificates 17 2 bytes for the bit string + 15 for extension parametersExtended Key usage should appear when appropriate 65 Consists of OID.Estimated at 5 OID = 55 Bytes + 15 for extension parameters CertificatePolicies should be present with OID 26 11 bytes for root entity OID + 15for extension parameters Basic Constraints should be present 19 4 bytesfor the Boolean + 0 bytes for the path since path is not being used + 15bytes for extension parameters Subject Key ID should be present 35 20bytes based on 160-bit SHA-1 hash + 15 bytes for extension parametersAuthority Key ID should be present 103 20 bytes for the hash + 64 forthe General Name- assumption that it could be URI + 52 + 4 for serial +15 for extension parameters Must not contain Name Constraint 0 0 Mustnot contain Policy Constraint 0 0 AlA must be used for OCSP and RM 90 64bytes for general name + 11 bytes for OID + 15 for extension parametersExtension - Subscriber Information 55 20 bytes for warranty account + 20bytes for device id + 15 bytes for extension parameters Total 193

[0248] OCSP Request - with Root Instructions & Extensions Size (inOCSPRequest{ Bytes) Size Calculation Comments TbsRequest { VersionInteger 4 RequestorName Name 132 Request { The Request structure repeatsfor each request in a particular OCSP request. ReqCert { CertID {HastAlgorithm { Algorithm OID 11 Parameters Defined by 0 Estimated as 0since no parameters passed on the Algorithm implementation. } }IssuerNameHash 20 IssuerKeyHash 20 SerialNumber 4 }  }  }  } Total(Without Extensions) 191 RequestExtensions { Nonce { OID 11 Nonce Value24 No requirements have been imposed on Nonce Value. Estimated at 24bytes } ServiceLocator { IssuerName 132 AIA 32 OID 11 }    } Total (WithExtensions) 401

[0249] OCSP Response - with Root Instructions & Extensions Size (inOCSPResponse{ Bytes) Size Calculation Comments ResponseStatus {ResponseBytes ResponseType OID 11 Response 32 } BasicOCSPResponse {TbsResponseData { Version Integer 4 ResponderID Name 132 ProucedATGeneralizedTime 32 } Responses   { Repeated for each response CertID {Algorithm { algorithm OID 22 parameters Defined by 0 Algorithm }issuerNameHash 20 issuerKeyHash 20 serialNumber 4 } CertStatus 8ThisUpdate 32 NextUpdate 0 Not to be used in root entity Responses }SignatureAlgorithm { Algorithm { algorithm 11 Parameters 0 } } 0Signature Value 128 } Total (Without Extensions) 456 ResponseExtensions{ Nonce { OID 11 Nonce Value 24 } CRLEntryExtension { Reason OID 11ReasonCd Enum 4 HoldInstructsonCd OID 11 HoldInstruction OID 11InvalidityDate GeneralizedTime 32 CertificateIssuer OID 11CertificateIssuerName Name 132 } CRLReason { Reason OID 11 ReasonCd Enum4 Time GeneralizedTime 32 } Total (With Extensions) 750

[0250] Valid request and response times for OCSP transactions andwarranty transactions and confirmation times for all transactions arepreferably specified by root entity 110. The following section describespreferred performance targets for the transaction coordinator. Theresponse times noted refer specifically to the system response time.Preferably, lapsed timeframes in which manual processes are completed(noting the need for verification and requesting it, filing claims,etc.) are also established.

[0251] Preferably, the validation request and response time (i.e., OCSP)is ten seconds or less for all response time transactions within theroot control infrastructure. Validation outside the root infrastructure(from customer to customer or customer to root) preferably does notexceed sixty seconds. The total round-trip time preferably does notexceed seventy seconds. Preferably the response time includes latency onthe Internet. The end-to-end response time preferably includes thelongest validation path (i.e. subscribing customer to relying customerto relying participant to issuing participant to root entity).

[0252] An illustrative performance requirement maybe as follows: No morethan 6 seconds between the post of a certificate status check to arelying participant's transaction coordinator and receipt of a responseand no more than 3 seconds to turn around a response to a certificatestatus check where the data for the response is locally available in acase where caching is in effect, proof of freshness (i.e., includingstatus of participant certificates in messages transmitted by theparticipant) is in effect, a certificate chain of two certificates isbeing validated, the transaction is a four-corner transaction, and thesystem entities are connected to a 10 Mbps LAN (rather than theInternet).

[0253] The warranty request response time includes offline transactions.Preferably, these offline transactions do not exceed an eight hourwindow starting at the end of a business day.

[0254] The response time for response to notification of lost,compromised, or invalid certificates preferably includes offlinetransactions. Preferably, these offline transaction do not exceed onehour.

[0255] The revocation of certificates also preferably includes offlinetransactions. Preferably, these offline transactions do not exceed onehour.

[0256] The transaction coordinator also preferably provides confirmationof transactions. Online transaction requests preferably receive statusconfirmation, including incomplete request or response, within seventyseconds. The transaction coordinator also preferably provides a methodof storing for retrieval incomplete transaction requests or responses, areceipt of request status, an incomplete request response, andtransaction queuing for incomplete transaction.

[0257] The transaction coordinator also preferably comprises transactionrecovery requirements. Appropriate system resource allocation preferablyallows for transaction roll-back.

[0258] The transaction coordinator also preferably provides systemfail-over requirements. In a preferred embodiment, the transactioncoordinator is provided with system redundancy, system/hot back-up, andredundancy within the public Internet.

[0259] During the development of the transaction coordinator, aperformance baseline in the development environment is preferablyestablished. This base-line information is used to improve theperformance of the application components on the development machineitself. However, to achieve a preferred target performance, appropriateproduction hardware capable of supporting the anticipated number oftransactions and a network with appropriate band-width are typically putin place.

[0260] The following sections discuss preferred tuning strategies forhigher performance of the transaction coordinator.

[0261] It may be possible to reduce the size of messages being passedbetween entities by eliminating some or all of the certificates sentwith each message. Typically the recipient of a message knows theidentity of the sender (i.e., his distinguished name as it appears inhis warranty certificate) and has access to his full certification path.Many of the needed certificates are also available from localrepositories.

[0262] OCSP checks performed as part of the authentication process maybe eliminated if the customer database is designed to reflect revokedcertificates and if authorization checks are performed against a user'sdistinguished name and certificate, as opposed to just its distinguishedname.

[0263] In a preferred embodiment described above, the transactioncoordinator stores raw transaction data and then parses the data toseparately store a subset of the data for billing purposes.Alternatively, however, this function may be offloaded to an off-lineprocess that monitors the raw transaction database and extracts relevantbilling data from the data stored in the database.

[0264] Co-locating the transaction coordinator and OCSP respondereliminates the need to sign and verify requests and to establish securesocket layer connections between these components.

[0265] Using secure socket layer between financial institutions andduring communications with root entity 110 typically eliminates the needto digitally sign each request message. However, digitally signedrequests provide a higher degree of security. Each participant maypreferably assess the risks involved with trading off security forperformance.

[0266] Caching OCSP responses typically improves the turnaround time byreducing the time it takes to send and receive an OCSP request to theroot entity. In a preferred embodiment, verification of OCSP responsesis performed as the data is put into the cache as opposed to performingverification as part of the on-line transaction processing.

[0267] In a preferred embodiment, a transaction coordinator may cachevalidity responses and use the cached responses to validate credentials.The period for which a response may be cached is preferably set as apolicy matter by root entity 110. This period may preferably be withinthe 4 to 5 minute range.

[0268] If a transaction coordinator implements the ability to usedcached responses it is preferably adapted to log their use for billingand audit as well as non-repudiation purposes. The logged informationpreferably indicates that a cached response was used to validate acredential rather than a freshly acquired response.

[0269] For high value transactions, a client application may prefer theuse of a fresh response rather than a cached response. Accordingly, in apreferred embodiment, transaction coordinators preferably get and use afreshly acquired validity response on explicit request to use a freshresponse rather than a cached response.

[0270] In a preferred embodiment, the recipient of a response checks thestatus of the responder's certificate. Alternatively, to eliminate thissecond request, the transaction coordinator may automatically includethe status of its certificate (as signed by the root) whenever it sendsa response to either a relying customer or to another transactioncoordinator.

[0271] The following section discusses testing of the transactioncoordinator. Preferably, the transaction coordinator is tested for theitems listed in this section.

[0272] In order to provide architectural flexibility, the transactioncoordinator is preferably ported to more than one hardware platform(e.g. Microsoft Windows NT 4.0/2000, Sun Solaris and Hewlett PackardHP-UX). This allows participants to choose their own hardware platformfrom the list of the supported platforms. Tests are preferably performedto ensure that the transaction coordinator is installed smoothly on eachof the supported platforms. To enable such testing appropriate hardwareis typically required.

[0273] Tests are preferably performed to ensure that the transactioncoordinator may be installed and uninstalled on a clean Windows NTMachine.

[0274] If the transaction coordinator is extended to support otheroperating systems, tests are preferably performed to ensure that theexecutable derived from the same source code can be installed on all ofthe supported operating systems. Appropriate hardware with appropriateoperating systems may be required to perform these tests.

[0275] Preferably, the transaction coordinator interfaces with otherthird party vendors' software tools. The interfaces to these softwaretools are preferably tested on the development site during developmentand system test phase. In addition, elaborate testing is typically doneat the customer site to ensure that the transaction coordinatorinterface with these tools is stable. This may be done duringcustomer/functionality testing, described below.

[0276] The functionality of the transaction coordinator is preferablytested during development and system test phases. During these tests,appropriate tools are used to ensure that all of the custom written codeis exercised at least once. In a another preferred testing phase,customers test the functionality of the transaction coordinator.

[0277] Security is a critical piece of the transaction coordinator.Preferably, testing is done to ensure that data is transferred securelyfrom one point to another. Test cases are preferably created toexhaustively test the security aspect of the public key infrastructure.

[0278] A messaging protocol definition for messages transmitted withinsystem 200 and a certificate status protocol definition for system 200are described in copending U.S. provisional patent application serialNo. 60/231,319, filed Sep. 8, 2000, entitled Transaction CoordinatorCertificate Status Check (CSC) Protocol Definition, TransactionCoordinator Messaging Protocol Definition, and Transaction CoordinatorRequirements, which is hereby incorporated by reference. In a preferredembodiment, each transaction coordinator supports this messagingprotocol definition. Specifically, each transaction coordinator acceptsand routes all valid XML messages as defined in the messaging protocoldefinition, logs and reports ill-formed messages, and is able togenerate valid XML messages in response to requests.

[0279] In an alternative embodiment, the system may instead beimplemented as an OCSP centric model that does not employ transactioncoordinators 202. This alternative embodiment employs enhanced OCSPresponders adapted to provide significantly more functionality thannormally provided by a typical OCSP responder. In particular, theenhanced OCSP responder is adapted to provide the following additionalfunctionality:

[0280] Encrypted communication using SSL.

[0281] Logging of raw transactions for both requests and responses.

[0282] Providing of certificate chains with responses.

[0283] Verification of signatures on requests preferably using an HSM.

[0284] Validation of certificate chains accompanying requests (parts ofwhich may be stored in a local database or on an HSM).

[0285] Creation of new requests based on:

[0286] A value in a service locator request extension of a receivedrequest.

[0287] An authority information-access extension in the certificateaccompanying a response.

[0288] Suspension of processing on a request until responses arereceived on these other newly created requests, i.e., ability tosynchronize responses to requests.

[0289] Forwarding of responses, when appropriate.

[0290] This alternative embodiment provides only portions of thecertificate status check service without providing the flexibility ofadding new services. Also, billing is not implemented in thisalternative embodiment. In addition, this alternative embodiment maycause vendor locking. A detailed list of the pros and cons of thisalternative embodiment is provided below.

[0291]FIG. 14 depicts the transaction flows for this alternativeembodiment. The message flows in FIG. 14 are summarized in the followingtable:  1 The Subscribing Customer (SC) sends signed data, thesignature, the SC and the IP certificates (and optionally CSSD) to theRelying Customer (RC).  2 The RC verifies the signature on the data sentby the SC and validates the SC's certificate chain and then creates anOCSP request containing the SC certificate serial number. This data issent to the USM for signature.  3 The OCSP request for the SC'scertificate, signed by the RC is sent to the Relying Participant (RP)OCSP Responder (OR) along with the RC's certificate chain. The entirecertificate chain must be passed with the message.  4 The RP OCSPResponder logs the request in its OCSP log. The RP OCSP Responderverifies the signature on the request and validates the RC's certificatechain. All verification if performed is software. The entire chain(including the root) must be passed with the message in order forverification of the signature/certificate chain to be performed. Nochecks are performed to ensure that the RC's certificate has not beenrevoked.  5 The RP OCSP Responder creates a new request, containing thesingle request received from the RC, and signs it using its HSM. Signedrequests between financial institutions are not required. Instead, theroot entity (ROOT) may require SSL client- side authentication in whichcase the verification/validation/customer look up is based on thecertificates associated with the SSL connection.  6 The RP OCSPResponder sends the signed OCSP request to the appropriate IssuingParticipant's OCSP Responder based on the value in the Service Locatorrequest extension of the received request.  7 The IP OCSP Responder logsthe request in its OCSP log. The IP OCSP Responder verifies thesignature on the request and validates the RP OR's certificate chain.All verification if performed in software. The entire chain (includingthe root) must be passed with the message in order for verification ofthe signature/certificate chain to be performed.  8 The IP OCSPResponder creates an OCSP request containing the serial number of the PPOCSP Responder's certificate and signs it using its HSM.  9 The IP OCSPResponder then sends the request to the ROOT OCSP Responder based on theauthority information access extension in the certificate associatedwith the signature on the request received in Step 4. The IP OCSPResponder waits for a response from the ROOT regarding the RP OCSPResponder's certificate before issuing a response on the SC'scertificate. If the IP only requires SSL client-side authentication anddoes not require signed OCSP requests, this step may not be necessary.10 The ROOT OCSP Responder logs the request in its OCSP log. The ROOTOCSP Responder verifies the signature on the request and validates theIP OCSP Responder's certificate chain. Signed requests between financialinstitutions are not required. Instead, the ROOT may require SSLclient-side authentication in which case theverification/validation/customer look up is based on the certificatesassociated with the SSL connection. 11 The ROOT OCSP Responder checksits local database to determine the status of the RP OCSP Responder'scertificate, then it generates a response and signs it using its HSM. 12The ROOT OCSP Responder then returns the response to the IP OCSPResponder. 13 The IP OCSP Responder logs the response in its OCSP log.The IP OCSP Responder verifies the signature on the request andvalidates the Root's OCSP Responder certificate chain. It should benoted, however, that there may not be enough information maintained inthe logs to support non-repudiation. The entire certificate chain mustbe passed with the message. 14 The IP OCSP Responder then checks itslocal database to determine the status of the SC's certificate. The IPOCSP Responder generates a response and signs it using its HSM. 15 TheIP OCSP Responder sends the signed response to the RP OCSP Responder. 16The RP OCSP Responder logs the OCSP response in the OCSP log. The RPOCSP Responder verifies the signature on the response and validates theIP's OCSP Responder certificate chain. The entire certificate chain mustbe passed with the message. 17 The RP OCSP Responder creates an OCSPrequest containing the serial number of the IP OCSP Responder'scertificate and signs it using its HSM. 18 The RP OCSP Responder thensends the request to the ROOT OCSP Responder based on the authorityinformation access extension in the certificate associated with thesignature on the response received in step 14. 19 The ROOT OCSPResponder logs the raw request in its OCSP log. The ROOT OCSP Responderverifies the signature on the request and validates the entire RP OCSPResponder's certificate chain. The entire certificate chain must bepassed with the message. 20 The ROOT OCSP Responder checks its localdatabase to determine the status of the IP OCSP Responder's certificate,then it generates a response and signs it using its HSM. 21 The ROOTOCSP Responder sends the signed response to the OCSP Responder. 22 TheRP OCSP Responder logs the response in its OCSP log. The RP OCSPResponder verifies the signature on the response and validates theRoot's OCSP Responder certificate chain. The certificate chain may bepassed with the message, or parts of the chain may reside either on theHSM or in the Certificate Verification database. 23 The RP OCSPResponder creates a response for the RC that contains information itreceived in step 2 (e.g., the nonce) and the status information on theSC's certificate it received in step 14 and signs it using its HSM. 24The RP OCSP Responder returns the response to the RC. 25 The RC uses itsHSM to verify the signature on the response and validate the RP's OCSPResponder certificate chain. The certificate chain may be passed withthe message, or parts of the chain may reside on the HSM. 26 The RCcreates an OCSP request containing the IP's certificate serial number.This data is sent to the HSM for signature. 27 The OCSP request for theIP's certificate, signed by the RC, is sent to the Relying Participant(RP) OCSP Responder (OR) along with the RC's certificate chain. Theentire certificate chain needs to be passed with the message. 28 The RPOCSP Responder logs the request in its OCSP log. The RP OCSP Responderverifies the signature on the request and validates the RC's certificatechain. All verification if performed in software. The entire chain(including the root) must be passed with the message in order forverification of the signature/certificate chain to be performed. Nochecks are performed to ensure that the RC's certificate has not beenrevoked. 29 The RP OCSP Responder creates a new request, containing thesingle request received from the RC, and signs it using its HSM. Signedrequests between financial institutions are not required. Instead, theROOT may require SSL client-side authentication in which case theverification/validation/customer look up is based on the certificatesassociated with the SSL connection. 30 The RP OCSP Responder sends thesigned OCSP request to the ROOT OCSP Responder based on the value in theService Locator request extension of the received request. 31 The ROOTOCSP Responder logs the request in its OCSP log. The ROOT OCSP Responderverifies the signature on the request and validates the RP OR'scertificate chain. All verification is performed in software. The entirechain (including the root) must be passed with the message in order forverification of the signature/certificate chain to be performed. 32 TheROOT OCSP Responder checks its local database to determine the status ofthe RP OCSP Responder's certificate, then it generates a response andsigns it using its HSM. 33 The ROOT OCSP Responder then returns theresponse to the RP OCSP Responder. 34 The RP OCSP Responder logs theresponse in its OCSP log. The RP OCSP Responder verifies the signatureon the response and validates the ROOT's OCSP Responder certificatechain. It should be noted that there may not be enough informationmaintained in the logs to support non-repudiation. The entirecertificate chain must be passed with the message.

[0292] This OCSP proxy centric model has advantages and disadvantageswhen compared to the transaction coordinator model described above. Thepros and cons of this alternative embodiment are summarized in the tablebelow: Pros Cons Takes away some of the complexity of Two OCSP Responderare required: one implementing the transaction coordinator as thatre-signs responses, one that forwards an initial phase by reducingfunctionality signed responses without re-signing. and pushing codechanges to the manufacturer of the OCSP responder. Allows the basicsecurity infrastructure to No authorization checks are performed. be putin place and tested. Signatures are verified by the OCSP Responder butthere are no checks performed to determine whether or not the request isfrom an authorized customer. There are no OCSP checks performed todetermine if a requestor's certificate has been revoked. Allcertificates in a requestor's/responder's chain must be sent with therequest/ response in order for the OCSP Responder to verify thesignatures. This significantly increases the size of the messages. TheRC must send individual requests to the RP - multiple certificatestatuses cannot be requested in the same message if they need to beprocessed by different OCSP responders. Not enough information ismaintained in the logs for non-repudiation purposes. It is not clearwhether enough information about the requestor is retained for billingpurposes. Can only perform certification status checks. Will stillrequire a transaction coordinator to fulfill other services. Will notprovide generic reusable core components. The TETF OCSP Responderspecification does not require Responder to provide this additionalfunctionality.

[0293] Technical and security requirements for OCSP responder 204 arepreferably specified by root entity 110. An exemplary set ofrequirements is described below.

[0294] Technical Requirements

[0295] In a preferred embodiment, each OCSP responder 204 operatespursuant to the Online Certificate Status Protocol (OCSP).

[0296] In a preferred embodiment, when an OCSP responder 204 receives anOCSP request, it validates the requestor's certificate, authenticatesthe requestor, and verifies that the requestor is a contracted systemuser with the participant that received the request by performing alocal status check on the requestor's certificate. Authentication of therequestor may be accomplished using the signed OCSP request, in the caseof an inter-institution request, or through secure socket layers clientauthentication, in the case of a customer request. In addition, securesocket layers may be required to ensure the confidentiality of allrequests.

[0297] In a preferred embodiment, each OCSP responder 204 selects peerservers when making inter-institution requests based on a locatorextension of the requested service and a local table. In an alternativeembodiment, this information may be obtained by lightweight directoryaccess protocol (LDAP) look up.

[0298] In a preferred embodiment, each OCSP responder 204 may cachecertificates subject to rules specified by root entity 110.

[0299] In a preferred embodiment, each OCSP responder 204 verifies thatinter-institution responses have been signed by an authorized respondercertificate. For inter-institution OCSP requests, the OCSP responder ofthe relying participant 204 preferably re-signs the response from, e.g.,issuing participant 102 before transmitting it to the requestor.

[0300] In a preferred embodiment, each OCSP responder supports thefollowing responses: “revoked,” “good,” and “unknown.” If a client OCSPresponder receives a “revoked” response regarding a particularcertificate produced at a time t, then the client OCSP responder assumesthat that certificate, or some certificate in the certificate chain ofthat certificate was revoked prior to time t. As such, the client OCSPresponder does not possess sufficient evidence to transfer liability fordocuments that have been digitally signed after time t using the privatekey corresponding to the checked certificate to the server OCSPresponder.

[0301] If a client OCSP responder receives a “good” response regarding aparticular certificate, produced at a time t, then the client OCSPresponder assumes that that certificate and every other certificate inits certificate chain was in good standing at time t. As such, theclient OCSP responder has sufficient evidence to transfer liability fordocuments that have been digitally signed prior to time t to the serverOCSP responder.

[0302] If the client OCSP responder receives an “unknown” responseregarding a particular certificate produced at time t, then the clientOCSP responder assumes that that certificate, or a certificate in thecertificate chain of that certificate, is not known to be in goodstanding. As such, the client OCSP responder does not possess sufficientevidence to transfer liability for documents that have been digitallysigned using the private key corresponding to the checked certificate tothe server OCSP responder.

[0303] Security Requirements

[0304] In a preferred embodiment, each OCSP responder 204 stores itsprivate keys in a hardware security module that meets requirementsestablished by root entity 110.

[0305] In a preferred embodiment, each OCSP responder 204 uses separatekeys for server secure socket layers, client secure socket layers, andOCSP responses.

[0306] In a preferred embodiment, each OCSP responder 204 has theability to operate on institution-hardened platform configurations. Aninstitution-hardened platform is a tried and tested platform that isapproved for use within an institution's firewall.

[0307] In a preferred embodiment, each OCSP responder 204 maintainsdetailed logs of all signed requests and responses, all exceptions orerrors, and all administrative and configuration actions.

[0308] In a preferred embodiment, each OCSP responder 204 uses strongauthentication, such as secure socket layers client authentication, toauthenticate entities for all administrative transactions.

[0309] In a preferred embodiment, each OCSP responder 204 meets minimumsecurity requirements established by root entity 110. In addition, theinstitution that maintains the OCSP responder may specify additionalOCSP responder security rules.

[0310] In a preferred embodiment, each OCSP responder 204 is configuredto be highly available and deployable in a replicated mode. In addition,each OCSP Responder preferably responds to all requests in less than onesecond.

[0311] OCSP responders are not typically required to perform checks onutility certificates. They may, however, be configured to allow arequestor unauthenticated access to the status of a utility certificate.

[0312] In a preferred embodiment, an OCSP responder may be required toserve as an authenticated interface to an institution's repository.Implementation details of this preferred embodiment may be left to theentity that maintains the OCSP responder.

[0313] In a preferred embodiment, each OCSP Responder comprisesadditional interfaces to support additional functionality. Inparticular, each OCSP responder preferably comprises an additionalinterface to make information available to support a participant'scustomer-service requirements. In addition, each OCSP responderpreferably comprises an institution-defined standard interface forexporting system and event logs. Each OCSP responder may also comprisean interface for export of information for billing applications. Billingdata may be exported in any format including logs but preferably enablesthe requestor to determine the type and volume of the request.

[0314] In a preferred embodiment, participants 102, 104 shown in FIG. 1are referred to as level-one participants because they are issueddigital certificates directly by root entity 110. Accordingly, thecertificate chain of each participant begins at root entity 110. Eachlevel one participant relies on root entity 110 to obtain the status ofcertificates of other level-one participants.

[0315] In a further preferred embodiment, the present system maycomprise additional participants, called level-two participants. Eachlevel-two participant is preferably issued a digital certificate by alevel-one participant with which it is associated. These level-twoparticipants may then serve as certificate authorities for theirrespective customers and provide system services to those customers.

[0316] Level one participants preferably provide the highest point oftrust for level two participants. As such, level two participantspreferably report directly to their sponsoring level one participant.Level two participants must also rely on their sponsoring level oneparticipants to obtain the status of certificates of other participants.A preferred embodiment including level one and level two participants isfurther described in copending U.S. patent application Ser. No.09/502,450, filed Feb. 11, 2000, entitled System and Method forProviding Certification-Related and other Services, which is herebyincorporated by reference.

[0317] In a preferred embodiment, each participant collectivelyimplements and maintains a hardware and software configuration baselinethat identifies the operating environment of the hardware and softwarecomponents of each participant. As such, the configuration baselineserves as a configuration reference which facilitates the dailyoperation and management of the system. The baseline facilitates theintegration of configuration changes made by one or more participants ona system-wide level. In addition, the baseline facilitates system-wideservice recovery in the event of hardware or software failures of one ormore certification authorities.

[0318] In a preferred embodiment, a master copy of the configurationbaseline for the present system is maintained by root entity 110.Typically, the master copy is kept by an officer of root entity 110,such as the Vice President of Operations.

[0319] In a preferred embodiment, root entity 110 keeps a true andaccurate record of root entity 110's hardware and softwareconfiguration. At least three copies of the root certificationauthority's configuration baseline are preferably retained by rootentity 110 at the following three locations: (1) at the same physicallocation of the root certification authority thereby allowingoperational changes to be recorded as they occur; (2) at a securelocation outside the physical location of the root certificationauthority but in a controlled container; and (3) at an offsite locationwith root entity 110's backup and archive records. Other copies of thishardware and software configuration may be provided to level onecertification authorities at the discretion of root entity 110.

[0320] In a preferred embodiment, each level one participant maintains atrue and accurate record of the hardware and software configuration ofits certification authority architecture. Each level one participantpreferably prepares, retains, and maintains at least three copies of itsconfiguration baseline document in the following three locations: (1) atthe same physical location of the level one certification authoritythereby allowing operational changes to be recorded as they occur; (2)at a secure location outside the physical location of the level onecertification authority but in a controlled container; and (3) at anoffsite location with the level one certification authority's backup andarchive records. In addition, each level one participant preferablyprovides a copy of its configuration baseline to root entity 110.

[0321] In a preferred embodiment, level two participants also maintain atrue and accurate record of the hardware and software configuration oftheir certification authority architecture. Each level two participantprepares, retains, and maintains at least three copies of itsconfiguration document in the following three locations: (1) at the samephysical location as the level two certification authority therebyallowing operational changes to be recorded as they occur; (2) at asecure location outside the physical location of the level twocertification authority but in a controlled container; and (3) at anoff-site location with the level two certification authority's back upand archive records. In addition, each level two participant preferablyprovides a copy of its configuration baseline to its sponsoring levelone certification authority.

[0322] Forms may be provided to facilitate documentation of hardware andsoftware configurations. In a preferred embodiment, the hardware andsoftware configurations of root entity 110's and each participant'scertification authority directory, OCSP responder, and Internet firewallare also documented.

[0323] In a preferred embodiment, root entity 110 has primaryresponsibility for configuration management on a system-wide level. Thisresponsibility is typically delegated to an officer of root entity 110,such as the Vice President of Operations. Each certificate authoritypreferably comprises a technical operations staff which has theoperational responsibility for maintaining an accurate record of thecertification authority's hardware and software configuration.

[0324] In a preferred embodiment, the initial configuration baseline ofeach certificate authority is produced by commissioning theconfiguration baselines of each subordinate certification authority.

[0325] In a preferred embodiment, a configuration change must complywith the following criteria: (1) a configuration change must be requiredto address a defined system requirement; (2) a configuration change mustbe recommended by the certification authority's operations staff; (3) aconfiguration change to the operational platforms must be approved by anofficer, such as the Vice President of Operations in the case of theroot entity, and a senior manager accountable for the integrity of thecertification authority, in the case of a level one or level twocertification authority; (4) notice of configuration changes must begiven to any affected parties; (5) a configuration change must take intoaccount relevant configuration change criteria imposed by governmentalor standards setting bodies; and (6) a configuration change must berecorded by setting out the date of the change and the period of eachprevious configuration. Each certificate authority typically archivesconfiguration changes with other archived materials such as backuptapes.

[0326] In a preferred embodiment, the configuration baseline isimplemented in conjunction with the root entity's system security policyand is an audited component of each certification authority.

[0327] While the invention has been described in conjunction withspecific embodiments, it is evident that numerous alternatives,modifications, and variations will be apparent to those skilled in theart in light of the foregoing description.

What is claimed is:
 1. A system for providing one or more services via anetwork, comprising: a root entity, the root entity operating a rootentity certification authority, the root entity maintaining a rootentity configuration baseline for the root entity certificationauthority, the root entity configuration baseline comprising theoperating environment of the root entity certification authority; atleast one level-one participant, the level-one participant operating alevel-one certification authority, the level-one participant maintaininga configuration baseline for the level-one certification authority, theconfiguration baseline for the level-one certification authoritycomprising the operating environment of the level-one certificationauthority; at least one level-two participant, the level-two participantoperating a level-two certification authority, the level-two participantmaintaining a configuration baseline for the level-two certificationauthority, the configuration baseline for the level-two certificationauthority comprising the operating environment of the level-twocertification authority.
 2. The system of claim 1, wherein theconfiguration baseline of each entity's certification authority isrecorded on a form.
 3. The system of claim 1, wherein a copy of eachentity's configuration baseline is maintained by the root entity.
 4. Thesystem of claim 1, further comprising a configuration manager, theconfiguration manager being an officer of the root entity, theconfiguration manager further having primary responsibility forconfiguration management within the system.
 5. The system of claim 1,wherein each certification authority comprises a technical operationsstaff, the technical operations staff having primary responsibility formaintaining record of an entity certification authority's configuration.6. The system of claim 1, wherein the configuration baseline for eachentity's certification authority is maintained at the same physicallocation of the entity's certification authority.
 7. The system of claim1, wherein the configuration baseline for each entity's certificationauthority is maintained at a secure location outside the physicallocation of the entity's certification authority.
 8. The system of claim1, wherein the configuration baseline for each entity's certificationauthority is maintained at an offsite location.
 9. The system of claim1, wherein changes to the configuration baseline of an entity'scertification authority are made to address a system requirement. 10.The system of claim 1, wherein an affected party is notified of a changeto the configuration baseline of an entity's certification authority.11. The system of claim 1, wherein a change to the configurationbaseline of an entity's certification authority takes into accountconfiguration change criteria imposed by government bodies.
 12. Thesystem of claim 1, wherein a change to the configuration baseline of anentity's certification authority takes into account configuration changecriteria imposed by standards-setting bodies.
 13. A system for providinga certificate status check service via a network comprising a pluralityof entities including at least one root entity, at least one issuingparticipant, and at least one relying participant, each entitycomprising: a transaction coordinator; an online certificate statusprotocol responder, the online certificate status protocol responderchecking status of a certificate, the online certificate status protocolresponder receiving online certificate status requests from thetransaction coordinator, the online certificate status protocolresponder sending online certificate status responses to the transactioncoordinator; and at least one hardware security module.
 14. The systemof claim 13, wherein the online certificate status protocol respondersends a revoked response regarding a checked certificate, the revokedresponse indicating that the certificate, or a certificate in acertificate chain of the certificate, has been revoked prior to aparticular time.
 15. The system of claim 14, wherein the issuingparticipant does not accept liability for documents that have beensigned after the particular time using a private key corresponding tothe checked certificate.
 16. The system of claim 13, wherein the onlinecertificate status protocol responder sends a good response regarding achecked certificate, the good response indicating that the certificateand every other certificate in the certificate chain of the certificateis in good standing at a particular time.
 17. The system of claim 16,wherein the issuing participant accepts liability for documents thathave been signed prior to the particular time using a private keycorresponding to the checked certificate.
 18. The system of claim 13,wherein the online certificate status protocol responder sends anunknown response regarding a certificate, the unknown responseindicating that the certificate, or a certificate in the certificatechain of the certificate, is not known to be in good standing at aparticular time.
 19. The system of claim 18, wherein the issuingparticipant does not accept liability for documents that have beensigned prior to the particular time using a private key corresponding tothe checked certificate.
 20. The system of claim 13, wherein the onlinecertificate status protocol responder stores its private keys in ahardware security module.
 21. The system of claim 13, wherein the onlinecertificate status protocol responder meets a set of minimum securityrequirements established by the root entity.